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.