How much does quality cost?

Aug 16, 2024 7:30 pm

Happy Friday,

When I work with leaders in most tech organizations, they almost all express a desire for their teams to go faster. The way they express this varies from small phrases interjected here and there to outright threatening people that they need to work longer and harder if they want to be employed.

So, what happens when you work in a place that values speed above all else? Low quality.

Quality is one of those words that can mean a lot of things to a lot of folks, so in any conversation, it's a good idea to help pin down exactly what aspects of quality are under discussion.

An easy number to calculate is called the innovation ratio, which is the amount of value-adding work compared to non-value-adding.

What this number helps show is where time and money are going. A place that tolerates low quality in favor for speed almost always has a low innovation ratio, and many leaders are shocked to find out that the harder the press for speed the more time and money they are losing to hotfixes, bugs, and rework.

The other really useful number is defect rate. The defect rate is the ratio of completed work to created bugs. This differs from the innovation ratio because the innovation ratio captures where you are spending time and money. Defect rate shows how much waste you create along the way.

Let me give some examples here to show what I commonly see. Many organizations have an innovation ratio of something like 2-3:1 in terms of value-adding to non-value-adding. That means they're producing 2-3 value-adding items for every bug or something. Yet, when I look at the defect rate, which is how many bugs get created for those value-adding items, it isn't uncommon to see 1:1-0.5. This means that for every value-adding item, they create one bug or half a bug.

In other words, they're producing more problems than they can keep up with. Anyone who wants to argue that they can run a successful software business like that is going to have a tough time.

So, how hard is it to correct these things? Some parts are pretty easy to fix. Others take a lot longer. It is extremely cost-effective to add automated tests to code, but altering how you release code is often much harder. Imagine, though, that a team shifted from focusing on speed at all costs to believing you move fast when you move well, and that started with automated tests. Over the next 6 months, the defect rate would begin to collapse. The types of quality issues the teams would see would move from being code and environment and integration to environment only.

Here's the wild part, the time it takes to produce those tests and the work that goes with it will stay roughly the same over time. In the beginning, things will slow down while the team learns and brings their code under test, but as everyone gets better, the difference in times becomes negligible. The reason for this is that while most folks know that developers' time isn't spent typing but thinking. A huge portion of that thinking is spent answering the question, "How does this work?" Working tests answer that question almost instantly and cover the time it takes to write new ones.

Quality almost always pays off. Most of the teams I coach will work 3x-10x faster than their peers and previous benchmarks and eliminate almost all sources of bugs. The longest bug-free run I've had is 2.5 years with a real product that people used.

Here's my weekly update for August 16th, 2024...

🗒️ The Dos and Don’ts of Refactoring

Refactoring is one of those terms that shows up almost daily with engineering teams, yet for most, the definition is pretty loose.

What’s more, that loose definition leads to actions that often have undesirable outcomes, delays, and arguments about how to handle the fallout.

So, let me break down how I approach refactoring with engineers and teams.

Click here to read more

🗒️ Can AI Replace a Scrum Master?

Some friends were discussing a post by Jeff Sutherland about how AI will make estimation easy.

What I thought was odd about that post was looking at where AI would begin to replace various Scrum activities, so I thought I’d plug in a prompt to see what AI will cook up for something like a sprint planning.