Quality, Speed and Cost

I was chatting with my barber today about a job he worked in a few years ago. The owner of the barber shop - who had never cut hair - demanded a 20 minute turn around on each appointment. In that time the barber had to welcome the customer, offer (and make) them a beverage, cut their hair, and take payment. He explained to his boss that those timescales were infeasible; he needed at least 30 minutes to get the job done or quality would be compromised. His concerns were dismissed - afterall, what difference in quality could ten minutes make? He would just have to work a little quicker. Furthermore, the economic argument was clear: at a rate of £20 per appointment those extra ten minutes would cost the owner £20 per hour. Unacceptable.

The rebellious barber defied his boss’ orders, spending 30 minutes on each appointment. For the first couple of months, he brought in less money than the other barbers working in the shop. Then something mysterious happened. Customers who had their hair cut by the barber would keep coming back to the shop, and insist on an appointment with him. Meanwhile, many of the other barbers’ customers would never return to the shop. Even when the other barbers had empty chairs, the customers who had returned would choose to wait in line. The barber was subsequently fired by his boss.

There are a few lessons in this story. Firstly, the shop’s clientele chose to sacrifice their time for quality. The barber offering quality built a following, while the barbers who rushed their work produced good short term results for the business but didn’t retain nearly as many customers. Whether the quality came in the form of a particularly good haircut or humorous conversation isn’t important. The important thing is that he paid close attention to his craft and knew what his customers wanted. With rushed, lower quality work you will need to continuously find new customers just to stay afloat. Quality attracts loyalty upon which sustainable businesses can be built.

So why did the barber get fired? Well, in this case it probably wasn’t good for business. Although customers came back, other barbers’ seats remained empty. The barber should have either convinced the boss to adopt quality across the business, acquiesced to his demands, or left.

In software development it is unfortunately common for non-technical business people to tell developers exactly how long a feature should take, rather than asking them how long they think it will take. In the past I have seen managers instruct developers not to write tests due to a lack of time. The result? Buggy software that gets progressively more difficult to modify with each modification made. While the barber has a chance to start again after every cut, the decisions that are made in software - good or bad - tend to stick around. Sprints end up being dedicated to bug fixing, during which no features are developed. All of the “time saved” early on is quickly lost and, before they know it, developers have been playing a game of bug-fixing whack-a-mole for five years. To top it off, the software still doesn’t quite do what it’s supposed to.

In my experience, this happens when businesses or developers do not effectively manage stakeholder expectations. When sales people don’t realise that rushing features will accrue significant amounts of technical debt they may agree to unreasonable terms in order to seal the deal. If, god forbid, most developers on the team don’t realise this, then those that do can spend hours cleaning up the others’ mess. These full time code cleaners are likely to be your better developers but their ability to contribute to new features will be crippled. They’re left frustrated and will eventually leave. It is essential that everybody is onboard; a penchant for quality and craftsmanship must be adopted across the business.

Counterintuitively, when developers slow down, development speeds up. Quality is greater in both function and form. And in the long run fewer developer hours are required, making the software cheaper too.

For further reading, I recommend you check out Martin Fowler’s post “Is High Quality Software Worth the Cost?”. I’m always interested in hearing your thoughts, so feel free to get in touch.