Why does software take so long? Discovering the true enemy of flow

A watched kettle never boils.

If you’re longing for a cup of tea, then your anxious attention on the kettle makes it seem slow to boil. But you can’t do much about speeding up the activity of boiling water. The real delay probably occurred earlier – in the time elapsed between the first urge for a cuppa and when you actually got round to filing the kettle with water and switching it on. Perhaps the phone rang. Maybe you and your partner needed to have a long row about whose turn it was to make the tea or wash a mound of dishes before you could fill the kettle! The task ‘boil water for tea’ was sitting in a queue behind other tasks.

This ought to ring bells for most software development teams – and yet worryingly, it doesn’t. All of our working life is filled with queues, but we’re blind to them. Rather than asking why it took us so long to put the kettle on, we stare at it angrily, willing it to boil and muttering about how long it takes.

Because we are so busy, we find it odd to realise that of a project’s total length, very little is actually work. It spends most of its time in a series of queues, ranging from really big and obvious delays, (waiting to have a team assigned to the project); to minor and almost untraceable ones, (a request for information in an email sitting unanswered in a colleague’s inbox).

Why don’t we see them?

Inventory queuing up in software development is invisible. Most of our work is made up of information: ideas, design and lines of code. If we double the number of requirements in a project, there is no warning bell that sounds. Developers in the department might look slightly more stressed, but there is no real way of knowing what the change has done to their work or to how quickly they will complete it.

But carrying large amounts of inventory is as risky for us as for a manufacturer or retailer. The longer part-completed work sits there gathering metaphorical dust, the greater the danger that the value could disappear altogether. The opportunity could pass, a customer might walk away, the market might change… The sunk cost would be irretrievably lost; the hours of time invested to date, wasted.

Queues have a major effect on our cycle time

In a system that had no queues at all, the cycle time would be the sum of all the activities. A project run with zero queues takes an extremely short amount of time. It is also very costly, because to have zero queues, you need to keep your people free from other work. If the fastest cycle time means zero queues, then long queues mean the opposite: the longer the queue, the slower the cycle time. This has a major impact on economics and risk.

Read the full InfoQ article here on how to measure the impact of queues on your business and what actions you can take to improve.

Related content