The perception of software quality

Avoiding the tradeoff trap

A lot has been written about software quality, both in so many many books, and in even more articles. And there are a lot of tools and metrics available to measure software quality. All these are well known, proven and accepted in the software community.

However, when building software products, developer teams often end up in a situation, where they feel nobody except them cares about quality. More often than not, this goes hand in hand with a situation, when a product is built and more and more features get added to it. The team can easily end up in situations, where the small refactoring is kept for later, the test cases not written or executed. These then accumulate over time, leading to a slower team, more time spent on bugfixing, and a decrease in motivation. This is especially true in a client-provider relationship, where results are measured on the visible outcome, on the amount of features delivered, on how fast things get done.

The feeling of being the only ones caring about quality depends a lot on how it is framed, and on the perspective. We as developers know how software is made, what the processes are, what quality from the inside and outside looks like. You can compare that to a craftsman, knowing exactly which material to use, which tools, how to turn the raw materials into a product. So for us, quality is something that is part of the process.

Those not knowledgeable in the craft and art, cannot be expected to see the difference in high or low quality, at least not in every detail. The same way we might not fully recognise the detailed quality of a crafted blade down to the metal treatment level, polishing methods, etc used by experienced craftsmen. So we fall back to judge based on the visible. The blade might look more solid, feel more solid, than the cheap knife from the $1 shop at the corner.

Internal and External Quality

We have a sense of the quality inherent to the product, which we attribute mostly to the visible. This is what Kent Beck describes as internal vs. external quality. The external quality covers the user experience, the pleasantness to the user, and all other visible features. Internal quality is not directly visible to those not directly being involved in the development process. It only becomes visible in symptoms over time, such as a slower team, because they have a backlog of bugs to fix, a slower product, because some urgent refactorings have been postponed, also known as the design stamina hypothesis. Bad quality hinders product innovation, and you end up paying a high price for low quality.

External quality is quality as measured by the customer. Internal quality is quality as measured by the programmers. Temporarily sacrificing internal quality to reduce time to market in hopes that external quality won’t suffer too much is a tempting short-term play. — Kent Beck, Extreme Programming explained

Trading Quality

When we, as developers, find ourselves in this situation, we mostly had some point in the past, where we allowed the situation to be framed in terms of the tradable quality hypothesis. We allowed quality to be traded off for cost or time to market. This is fine, when applied to external quality, such as making an existing feature better instead of adding another feature, if this decision generates more value for the end user. This is a decision, also those can take, who only see the visible. However, when we allow to trade internal quality, we will lose, because it is then not perceived as something that adds value.

Saying that we need to spend less time adding new features to improve quality is just nailing down the lid. — Martin Fowler

The true value of internal quality however is that it enables teams to go fast. It is an investment in the future of the product, as you avoid hidden cost. To come back to the knife metaphor: buying the $1 knife, we have learned that we will buy a new one next month. So we understand the value of the handcrafted blade. However, this reinforces the notion, that we can trade quality. To bring in the perspective of internal quality, as an enabler for speed, we shall see the metaphor as: you buy the $1 knife, knowing that it will last for a month, and in a months time, when it breaks its price is going to double (or you’ll have to wait longer to get a new one).

Avoiding the Tradeoff Trap

As written initially, it is mostly not a problem of not having the right methods or tools, but a problem of creating the right perspective for all stakeholders of a product. It is hence part of the team’s responsibility to make sure internal quality is not up for the trade.

1. Educate

Raise the awareness that internal quality is not something that can be traded for new features. Educate the stakeholders about the long-term impact of bad software design on maintainability, and hidden cost in the future.

2. Visualise Quality

By visualising quality in the team you create a shared view, and also agree upon what is expected to be delivered in which quality. Multiple measures such as proper user stories, clear definitions of done, and sprint reviews are suitable to visualise how quality plays a core role in the product.

3. Estimate with Quality

Whether you’re using an agile framework like scrum or not, at some point you will end up estimating the effort you have with implementing the requested functionality. We are not only tempted to underestimate complexity, but also are tempted to see quality as something that comes after the actual implementation. With this mindset, we easily fall into the trap of not estimating the effort required to build the proper internal quality into the product. This then leads to follow-up tasks, which are pure ‘bugfixing’ user stories.

4. done-done-done

Especially when working task or user story based, we find ourselves tempted to call “it’s done”. Mostly it means, that we are done with a piece of the task. We completed the difficult algorithm that kept us awake at night, and call it “done”, however, it is not yet covered in tests, and not yet deployed to production. The key here is to explicitly communicate what is done. This can either be done, by using the term ‘done-done-done’ meaning all aspects are completed, or going to a finer granularity of status reporting.

5. zero bug policy

Make bugs first class citizen in your process. Visualise your bugs on the storyboard. Make them stand out visually, by giving them a separate color. Always fix bugs first. There’s no backlog of bugs, and no estimations for it. All features and improvements will have a lower priority, leading to higher quality, more speed, and most important, a happier team.

Like in all situations where a team has to make tradeoffs, and especially in the process of building a digital product, it is helpful to take the other person’s perspective and understand the problem from their view. Then, setup processes, measures, and communication that you don’t end up in the tradeoff trap.