Andy Hedges' Blog

How To Care About Software Quality

One of the oldest project management concepts I can remember being told about is the project management triangle. Whilst the project management triangle is largely misleading and quite frankly dangerous if taken literally it does at least tell you one thing: there are trade-offs in any given endeavour. For the classic project management triangle the trade-offs are three things with quality overlaid in a clumsy way. Those things are: cost, scope and time.

The theory is:

  • If you have enough time and money you can deliver your scope
  • If you have enough time but not enough money then you’ll have to deliver less scope
  • If you don’t have enough time but enough money then you’ll also have to deliver less scope
  • If you don’t have enough time and money then you are doubly in trouble and likely won’t deliver much of anything

Of course this is a very naïve way of looking at things and won’t get you very far. It doesn’t take into account things like morale, motivation, team politics, shared purpose, force majeure, health, ethics, sickness, personal life, indecision, competitor disruption and all those things that make humans and business such wonderfully complex and interesting things.

The triangle, as I’ve mentioned, has quality as its background, meaning I suppose, you can sacrifice quality to claw back time, costs and/or scope. Think about this though, can you really? Perhaps you can in the short term, how about the long term? If my team and I produce shoddy code that’s hard to read, has scattered concerns and global knots and all those bad things, then how am I going to keep delivering to functionality, at pace and within reasonable costs? This seems obvious, however it is missed or ignored remarkably often in small and large organisations alike.

The point is that if you sacrifice quality for short-term delivery of scope or to keep costs down then it will cost you more or you’ll get less in the future. Moreover it will cost more, take longer and deliver less for every subsequent project on that system. Until you’ve improved the quality back to an acceptable level you’ll be paying for that quick or cheap delivery in opportunity cost. Worst of all at a certain quality point the quality deteriorates faster and faster - interest is accuring on that technical debt.

Technical Debt

Ward Cunningham coined the term technical debt to describe this and like real financial debt it isn’t always desirable to avoid it. Just like in business taking on some debt can be a good thing, it can allow you to grow your business faster than otherwise and pay it back before the interest mounts. The same is true of technical debt. However, just like financial debt, if you keep on taking out loans and not paying back any of your debt the interest mounts and eventually the insolvency officers move in and shuts you down.

In software terms the insolvency will manifest in a number of different ways, technical bankruptcy looks like:

  • Every time you introduce a new feature another feature breaks (sometime referred to as the whac-a-mole problem)
  • Many of your best people leaving because they cannot take pride in what they are building (usually you end up with a churn of short-term contractors before eventually that costs too much to justify)
  • A competitor out pacing you and taking your customers

What we have to do is look at the reasons for poor decision making and ensure we can avoid them. Why do organisations, decision makers ignore software quality and therefore long term growth to pursue short term goals?

Financial Cycles

Most companies run their finances monthly and then annually, there is nothing else that matters to some people than the end of period figures. If you’ve ever spoken to an accountant at the end of the month they are usually a jibbering wreck from burning the midnight oil and if you speak to them during end of year you can forget any chances of getting some sense out of them. Not that the accountants are to blame they are just the messengers.

This is because the books have to be closed, the results have to be calculated and everyone wants them to look as good as possible to investors, bosses, themselves or whoever. What this creates is a sprint for the line at the end of each period. What happens when you sprint for the line? You give it everything you’ve got, abandon all strategy and then collapse in a heap once the line is passed.

In software quality terms this is a disaster. It means that everyone burns the midnight oil, shortcuts are taken to get features in, testing slips and shortcuts are taken. When all is said and done a few targets might have been reached but actually the code is now a steaming heap of rubbish.

Hidden Cost

In order to really understand software quality you have to really understand software, this means understanding many complex things like: systems design, software design, at least a few programming languages, data design and so one, who understand these things? Not many people, that’s who, and these people are busy creating new software and not explaining the implication of poor quality software in a language business types will understand. Typical those people, as bright as they are, aren’t the best a translating software quality issues in to monetary figures.

It’s by the nature of the complexity of the problem that few people understand its implication and often not the people (trying) to count the costs.

Opportunity Cost

This is a huge hidden cost and as such is called out separately. Opportunity cost is the difference between the value of the selected approach and the best alternative. In simple terms if I select an approach that makes me £100 over one that would have made me £250 then I have an opportunity cost of £150.

It’s an interesting concept and it applies to software in the following way. Let’s for example say I want to add a cool new feature to a mobile app. It costs £1000 to write the code to do it one way (code change A) and £3000 to write the code a better way (code change B). The first reaction is to pick A. However code change A will increase support costs by £250 a month. Moreover it will make the cost of doing the next change £1000 more expensive.

Now the opportunity cost is £250 after the 5th month and growing every month. Moreover it might mean that the next change doesn’t get made because it’s too expensive or worst still it is done in a suboptimal way meaning that it too increases opportunity cost compounding the problem.

Transient Team

A stable team is key to keeping a good quality software product. If you know you are going to be looking after the software in 3 years’ or 5 years’ time you are going to have a lot more invested in making sure it works and that it is a pleasure to support than someone who’s going to be off at another company or client in 3 months’ time.

Don’t get me wrong, I’ve worked with some amazing and dedicated people who’ve came and gone from teams quickly for whatever reason, however, on the whole, the tension isn’t there to think long term.

Unengaged Team

Things get to a point where design decisions have been overridden so many times to meet short term goals that the team stop fighting it. When this happens it’s a sad thing, you have an unengaged team who can’t take pride in their work and aren’t delivering the value they are capable of.

Reward Schemes

Similar to financial cycles more often than not companies will award bonuses annually for meeting certain goals. Getting a certain number of features added or perhaps getting X million sign ups or shifting Y million licenses. This triggers the target fixation mentality, where anything and everything is done to get these things achieved no matter the debt and damage incurred to the quality of the software.

Additionally next year’s bonuses will be negotiated from the point of knowledge of the software at the end of this year. Highly debt laden system will have the bonus hunter negotiating for lower barrier goals. If they don’t get them they move on and someone else moves in and does the same anyway.

Some Solutions

Listen to the Experts

There are no easy solutions in this, however things that help are a voice for the people who understand the complexity of good software. Listen to you developers, listen to the designers and architects. You’ve hired them for their expertise so use it.

Help Them Explain

Accept that the technologist might not be able to put a financial figure on the costs, help them with that, come up with mechanism that works for both the technologists and the accountants, make balanced decisions based on the circumstances. Remember the best software solution might not always be the best decision for the company but it quite often is.

Manage Your Tech Debt Like Any Other

Have technical debt reduction as a metric that is rewarded equally or more than adding features.

Start to show technical debt on your P&L report, take it seriously because it is a very real thing that has brought down more companies than we’ll ever know.

Set Long Term Goals

Have bonuses rewarded over 3 years too, supplement annual bonuses with some longer term goals around software quality.

Stabilise Teams

Value a stable team over transient teams, do everything you can to keep the loyal people loyal and support them in their quest for long term software quality.


Software quality is incredibly important, it’s the long terms viability of any technology focused company. Without it you are entering a downward spiral to technical insolvency. Take it seriously, sure, don’t be frightened to add a little technical debt now and then, but do it consciously, record it and pay it back in a prudent manner.

Andy Hedges