The state of software development accreditation (and why technical tests are needed)

The need for technical tests when hiring software developers (of mid-junior experience) is a sign of 2 things:

1) The industry is not regulated and does not have the backing of professional certification authorities to enter the industry, which would largely negate the need for the rudimentary testing we see across the board today.

2) Our education institutions (e.g. universities) are failing when their name and reputation is not enough to get the “average” candidate through the door without the need for additional testing (not talking about the FAANGs of the world).

(Speaking primarily from observation in Australia.)

Do we need regulation and accredited certification in the software industry? Hell yeah!

The software industry might only be a a handful of decades old at this point, but the exponential impact software developers have on the world means we can’t wait the 500 years other accredited industries have had to see people requiring accreditation before they can practise the craft.

Software Developer Priorities

Reading threads on Twitter, it’s a telling sign that almost all discussions from software developers/engineers I follow revolve around code, software architecture and technical stuff.

Very few think to mention customers or the greater impact on people from what do.

My priorities are:
1) People. Our customers.
2) Security and data privacy.
3) People. Our customers.
4) Code.

(The only reason security isn’t #1 is because without people, security isn’t a concern in the first place.)

But to be clear, I do spend a hefty amount of time thinking about code and software architecture. They’re just not my priority.

Dark Matter Software Developers

Let’s not forget, for every software developer who is active on social media, blogging or the speaking circuit – there are at least 100,000 developers working 9-to-5 jobs and keeping the world running. People you’ve never heard of and don’t have open source projects.

These people are the backbone of our economy.
They do their best while living full, balanced lives.
And a lot of them are as wise, if not wiser, than the big names and voices in our industry.

Let’s also consider: there are no Einstein’s in software development yet – only people who have written books, made their name on social media, or got lucky building a publicised software company.

Software development is an industry founded primarily on collaboration, incremental development, and more failure than success.

So, remember the quiet person who does their contractual hours every week and contributes to a product that affects thousands of people.

These are the people we must celebrate.

“Doing Cloud Software” – Since Before It Was Fashionable

I’ve been doing “cloud software” since 2007 – the year I registered my first domain.

I built and hosted my first website on https://discountasp.net/.
And I’ve since built WordPress websites that run in cPanel on system managed by https://www.digitalpacific.com.au/.

I’ve never had to create a network or a virtual machine.
Every software product I’ve designed and build has run on platforms other people mange, and service I can just deploy into.

DiscountASP.net gave me an ASP.NET platform and SQL Server.
Digital Pacific gave me PHP, WordPress and MySQL.

I never had to worry about infrastructure – just my application code. The rest was APIs.

Since then I’ve moved to Microsoft Azure and used only their serverless offerings – what is now Azure App Services, Azure SQL, Functions, Table Storage, Blog Storage and now Cosmos DB.
All “API” based.

I’ve never had to worry about infrastructure or anything I couldn’t access and control via a dashboard.

And to be honest, any time someone talks about Docker or Kubernetes, I can’t help but think “that sounds like too much work”.

.NET Linq .Select() often means “project”

I’m old school so I haven’t worked much with Linq (Language-Integrated Query (LINQ) (C#) | Microsoft Docs) – beyond the absolute basics – until this year.

One of the methods I’ve needed to use quite a bit is the Enumerable.Select Method. Which has been hard to wrap my head around until I realised something:

The method name doesn’t fit my mental model.

And the reason is in the first line on the Microsoft documentation page:

Projects each element of a sequence into a new form.

The key word being “projects” (as in, a “projection”). Which in cody-cody speak means “take the data I’m giving it and turn it into something else”.

See, when I see “select” I think of SQL “SELECT”, and in most cases we’re just picking data columns you want to return. Though, to be far, now I think about it you can also “project” with it.

But still, when I think “select” in the context of data it’s “you’re going to give me some data, and I’m going to pick the bits I want”. Whereas with “project” – particular in the context of the code I’m working with – means we’re “transforming” the data and often pulling in other data peripherally linked to it (in a way acting as a join). This is often doing by calling another method that takes the current item in the data and does something with it – e.g. used some value from it to lookup or generate other data structures.

The Microsoft docs page Projection Operations (C#) | Microsoft Docs start with the following which explains it well:

Projection refers to the operation of transforming an object into a new form that often consists only of those properties that will be subsequently used. By using projection, you can construct a new type that is built from each object. You can project a property and perform a mathematical function on it. You can also project the original object without changing it.

So what I need to do in a lot of cases for the code I’m dealing with is mentally swap .Select( x => x. ... ) for .Project( x => x. ... ) and it makes much more sense.

Advice for business people working with software developers (understanding what developers actually mean)

As a veteran software developer who understands both how software developers think and operate, as well as the positioning of business folk, I often seen the following situations arise and the disconnect that never seems to be addressed.

This article is written for business folks who work with software developers.

 

When a software developer says something is “easy”.

Software development is not easy. Ever!

It is a complex, complicated, time consuming process. This is the truth.
Any developer who disagrees with it is either a savant genius (doubtful), lying (not very likely), doesn’t yet have enough experience to understand (likely), or hasn’t “stepped out of their shoes” to properly think about it (most likely).

So when a developer says something is “easy”, what they really mean is:

Based on what you’ve told me, it sounds like I need to do something I’ve previously done, or it’s something I’ve learnt about, which I’m confident I can do without a much extra learning or mental effort.
And I’m just going to ignore for now anything that can trip me up in the process.

A couple of things to know about the “common software developer” and the software development process:

  • Developers are optimistic. Personally I think it’s part of the nature that makes them a developer. It’s a “can do” and “anything is solvable” attitude that drives them to find solutions and innovate.
  • There many of unpredictable things that can, and quite often do, go wrong. Such as:
    • A single character typo that takes half a day or a good night’s sleep to find.
    • A software dependency changes and breaks everything.
    • What seemed like a simple approach doesn’t work.
    • Implementing it is more complex than first thought.
      There are many, many more variables and conditions that need to be considered than were evident in the initial brief.
    • After building the thing it doesn’t work as expected. Or performance is nothing like expected.

And we also have to keep in mind if the person saying “it’s easy” is also the person who has to do the actual work.
Are you asking an architect with 20 years in the industry (and who may also be out of touch with the actual tooling and development process) while a developer just out of university is the one tasked with implementation?
Conversely, are you asking junior developer without experience yet?

Finally, many developers don’t like to say “no”, disappoint a boss/senior, or appear to not know what they are doing.
Many developers also fear for the security of their jobs, and by extension saying something is “not easy” can show weakness in their ability.

It is my belief that “it’s easy” is one of the primary reasons software development projects fail, in part because the question of “how hard is it?” is also the foundation for my next point.

 

When a software developer gives you a time estimate.

The golden rule of software development estimation is:

Multiple by 2.5

This is not in any way a joke or exaggeration.

Software developers are optimistic, shit at estimates (see the discussion above) and, my personal belief, we very quickly learn to estimate based on what we learn the business “wants to hear” vs what we really know to be true (let’s face it, most of the time the business is going to be pushing for an externally driven deadline regardless).

I’ve been estimating for 20 years and I still regularly get it wrong. Estimation is hard. There are so many unknowns and unpredictable external influences we have to contend with.

Unless you are absolutely confident the person you ask padded the estimate, then as a business person any estimate you receive from a developer should be multiplied by 2.5 for an accurate idea of how long it will take to implement.

Now, a crucial point on this is the word “implement”, which means “the time required to spend working on the task” (i.e. working hours).
It does not mean “it will be finished in that amount of time after it is started”.
It is not a delivery time.

When working on a task, a huge chunk of software development is more than just writing new code. It is:

  • Thinking.
  • Scrapping or changing what’s already been built.
  • Integrating into a larger project (and often having to make cascading changes across the project).
  • Testing.
  • Researching.
  • Discussing with colleagues.

A note on “testing”: Developers will not factor in time for testing in estimates, almost guaranteed.

On top of that, anything but the smallest task cannot be completed in one sitting.
Even a task that can be finished in 4 hours will need to split split over multiple days, to take into account time to think, time to test (especially if other teams are involved), general interruptions, and meetings that come with working in a business.

One final tangential but related point is around asking for progress updates.
There are a few of things to think about when asking for an update:

  • Be clear about whether you are asking “how much of the expected time is taken” vs “how much of the feature is complete“?
    Unless you ask specifically for a time based answer, assume the answer will be in terms of feature completeness and expressed as a relative value, either a percentage (e.g. 80%) or a vague “almost done”, “half way”, “only just started”.
  • A percentage of feature completeness is not proportional to the time taken.
    • A task that is 80% complete does not mean “80% of the time is used”.
      Nor does it mean the remaining work should take only 25% more time (math lesson: 20% of 100% is 25% of 80%).
      Many tasks can reach 80% complete in just 20% of the estimated time (and some can take 250% of the remaining time to complete).

Above all, NEVER hold a software developer to an estimate!

Dr Evil: We'll ask for estimates and treat them as deadlines.

It’s a well known joke in the industry, but it’s also a reality (I’ve been subjected to this many times over my career) and it is, to put it quite bluntly, a fucking toxic approach at will destroy your credibility with the very people you rely on.

Hopefully by now you realise why an estimate cannot be considered a deadline.

On the matter of estimates vs deadlines, here’s the best approach to take:

If you have a deadline that must be met, set it upfront and only use estimated for approximate planning.
Estimates are otherwise worthless in this scenario.
Instead, make a call on “feature completeness”, “quality”, resources working on the solution, budget, and what other work can be dropped.
And always assume when hitting deadlines developers are going to work at least 25% more hours than a standard work day.
(The only think more stressful to a developer than an estimate, is a deadline.)

Otherwise, if you want an estimate then treat is as a “rough idea”.
Assume the plan and schedule will change.
Don’t create any business critical plans against it.
And ensure the work is not part of something that has deadlines.

 

Bonus: How many hours can a software developer work behind a keyboard?

Software development is hard work.
It’s mentally and physically exhausting and requires a lot of stamina, especially over a long term, and especially of a term of sustained effort.

My rule of thumb is:

In a standard 8 hours work day, assume a maximum of 6 hours behind the keyboard.

That’s an absolute maximum. It’s not going to be every day. And that’s if you want quality work.

Remember to factor in things that take people away from the keyboard:

  • Meetings
  • Planning sessions (eg. at a whiteboard).
  • Coffee breaks and water cooler chats (essential for workplace productivity, and often a source of ideas and inspiration).
  • General break to clear the mind.

But software development is not about being behind a keyword and writing code. A huge percentage of it is thinking and learning/research.

Software development is not factory line work and cannot be thought of the same way in terms of output. It is creative and analytical.

And not every day is going to be the same.
Some days a developer will be in “flow” (a mental state when they are churning out code in a easy, satisfying way).
Some days personal life may be making them a bit flat.
Some days they will be battling technology gremlins.
Some days in their flow they will punch out a solid 10 hours of work.
The next day they’re fried and admin tasks or a bit of learning is the best you can hope for.

Software developers are people.
Not machines.
Not “resources”.
People with brains and bodies and lives like everyone else, who have the same ebbs and flows and worries and energy as everyone else.

Twitter Thread: Ranting about “right” and “wrong” architecture

I just posted a Twitter thread (a short rant, really) about software architecture, patterns and practices, and the “right” and “wrong” way.

You can find it at https://twitter.com/GDayJason/status/1359409433521004547.

But here it is in it’s entirety as well. Double-line spaces show the break between each Tweet.


I’m doing some .NET Core training on Pluralsight and along the way diving into REST API architecture and other related topics.

The thing that really shits be about architecture discussion and training is all the “you should do X” but no one EVER explains WHY!

 

 

If you’re going to write a document or build a training course that states a right way and wrong way, then explain why.

Why should I listen to you otherwise?

Give me pros and cons and concrete examples I can learn from. Help me “understand” to make good decisions.

 

 

But once again, I come back to a point I often make: “Most patterns and practices in software development are just MARKETING.”

They’re the opinion of one or a handful of people who decided how something should be done and wrote a book (or thesis) on it.

 

 

Oh, the ideas might have merit, but don’t been fooled by a flashy cover or title known to all.

These ideas are conceived and written by people just like you and me.

The danger we then face is new and good ideas are poo-pooed with “that’s not how it’s done according to X”.

 

 

Here’s the thing: “Today’s best practise is often tomorrow’s anti-pattern”.

Or it might still be a good practise, but other ideas have come to play as technology evolves.

 

Here’s the thing: “Today’s best practise is often tomorrow’s anti-pattern”.

Or it might still be a good practise, but other better practices have come to play that reflect the evolving technology.

 

 

There’s space enough for different ideas. Including ideas the CHERRY PICK from multiple practices to best fit the situation.

 

 

There’s space enough for different ideas.

Including ideas that can be picked from multiple practices to best fit the situation.

 

 

At the end of the day there is one, and only one, thing that truly matters:

The software solves a business problem.

Yes – maintenance, testing, readability, etc. But none of that matters if the product isn’t solving a problem AND being used.

 

 

But this is just my opinion.

I don’t do conference talks. I haven’t written a book.

I just have 20 years working with a lot of projects and solutions – some mine, many inherited.

And if I had a dollar for every time I saw something done the “wrong” I’d be well retired now.

 

 

And the #1 thing every single “wrong” solution I worked with did right?

It solved a real business need.

(And most developers could happily keep it running.)