Quality - The unknown entity - Part 3

Why quality probably is not what you think

Uwe Friedrichsen

10 minute read

Section of a sailing ship's sail

Quality - The unknown entity - Part 3

This is the third post of a blog series discussing quality.

In the previous post we discussed that we need to make quality measurable to create the required shared understanding. We also discussed that many people do not understand how their demands affect quality (and how we need to help them). And we discussed that we need to deal with the fact that quality attributes can be conflicting.

In this post we discuss that quality always lives in a larger context that affects the different quality attributes.

Quality lives in a context

Quality, while already being a complex, multi-dimensional beast, cannot be discussed without taking the context into account.

Typically, software development happens in the context of a project or a product development.

Quality being one of the dimensions in a project manager’s magic triangle. The other dimensions are time and scope, and budget delimiting the perimeter of the triangle.

If we look at the well-known project manager’s magic triangle, we see that quality is just one of the forces that need to be balanced in a project.

Time, scope, budget and quality create 4 conflicting forces in every project. 1

  • If you want to meet an ambitious deadline, you either have to reduce the scope or the quality. Increasing the budget usually does not help with a tight deadline because according to Brooks’s law “adding manpower to a late software project makes it later” 2. This only leaves the options to either reduce scope or quality.
  • If you want to increase the project scope, you either have to postpone the delivery date, increase the budget or compromise the quality.
  • If you want to improve the quality, you either need to increase the budget, postpone the delivery date or reduce the scope.
  • And so on.

In reality, usually a combination of the alternative options is chosen. E.g., to increase a given project scope, you usually increase the budget and postpone the delivery date a bit (and unfortunately, you often also reduce quality a bit).

The key observation is that it is not sufficient to balance the different quality attributes in isolation. Quality as a whole also needs to be balanced with encompassing forces which also affect the concrete design of the different quality attributes.

Cutting the wrong corners

Very often, we still see projects that start with a fixed budget and delivery date, which only leaves scope and quality as degrees of freedom. The project budgets typically solely belong to business departments. Software development is considered an execution department without its own budgets and thus without a stake in the discussions.

The product managers from the business departments (understandably) try to make most of their money and thus push to maximize scope as much as possible.

With time and budget being fixed, this only leaves the reduction of quality to compensate for the maximization of scope. And as software quality usually is poorly understood (not only) by non-IT people (the overall subject of this whole blog post series) and software development does not have a stake in the discussions, this is exactly what happens in such a setting. 3

It is harder to cheat on runtime related quality attributes like availability or usability. This becomes visible quite quickly. Therefore especially in project-driven contexts development related attributes like maintainability or evolvability get cut first. The effects of such quality cuts do not become visible within the duration of the project, but only later (i.e., in all subsequent projects).

This way of developing software, not thinking beyond the scope of a project and all budgets belonging to the business departments therefore leads to problematic effects regarding quality. In such a setting the conflict between the forces time, scope, budget and quality tends to be resolved to the detriment of quality.

Finding the right balance

This is one of the reasons why we often see very heated discussions in the developer community regarding quality along the lines of, e.g., clean code or unit test coverage. These are measures to improve development related quality attributes like maintainability or evolvability – the attributes that often first fall prey to the struggle between time, scope, budget and quality.

Here, it is important to find the right balance. It is definitely important to clearly object if someone attempts to cut (development related) quality as an easy way out to save money or increase scope. 4

On the other hand, dogmatism as we also often see it in the developer community, where clean code or test coverage have become an end in itself, also does not help. We also need to take the other dimensions like scope, time and budget into account when discussing quality.

If you only have a 3 months’ window of opportunity before your competitors are going to release their solution and snatch your market share, you only have 3 months. Insisting in such a situation, e.g., that you need to clean your code, is probably the wrong discussion. The same is true if you only have a very limited budget to get something accomplished for a good reason (not just because someone specified a budget before the scope was defined).

Still, this does not mean that you need to give up on all quality goals in such a setting. Discussing scope is also a valid means to meet a time or budget deadline. The key point is that it is not about all or nothing, but about finding a sensible compromise that takes current and future needs appropriately into account.

Projects live in a context, too

The preceding examples indicated that projects (as well as product development) also live in a bigger context which typically is the company context. The appropriate balance of the 4 project forces time, budget, scope and quality always depends on the context a project lives in.

Projects themselves are embedded in the larger company context that impose forces like market pressure, product uncertainty, financial situation, company maturity, existing organization and processes as well as people and their culture on the project.

Again, there are a lot of forces and drivers that need to be taken into account to find a suitable balance. The image lists some of the most obvious ones. All these forces affect the projects and how they need to be balanced in terms of time, scope, budget and quality.

Taking the larger context into account

Let us take an (admittedly) extreme example for illustration purposes. Let us assume that your company is a startup with a seed funding.

In such a setting, lengthy discussions regarding code quality or test coverage can kill your business before you have earned your first Euro. Focusing on great quality in such a context does not make a lot of sense: You are looking for a product-market fit. This means your top goal is to test as many hypotheses as possible in as little time as possible. Remember: You need to find a product-market fit before the funding is used up.

90% of the code you write today will be useless (and deleted) tomorrow. Thus, fostering code quality and test coverage in such a setting would not only be dangerous for the survival of your company. It would also be a complete waste of time and resources. 5

Let us contrast this with a quite different counter-example: You work on a core system of a well-established enterprise. End of lifetime of that system is still years away. Here you most definitely need to take care of good code quality. Not doing so in this context would not only be a waste of money due to much higher costs over the system’s lifetime. It would also be annoying, stressful and frustrating for all people involved – not only the developers.

These were two pithy examples without claiming to cover everything. Still, they should be sufficient to understand that there is not a “one size fits all” regarding quality in a project or product development context. The adequate degree of quality is highly dependent of the context the project/product lives in.

While, e.g., 80% unit test coverage might be a great idea in one place, it might be a bad idea in the other place. While 99,9% availability might be a great idea in one place, it might be a bad idea in the other place. And so on.

You always need to look at the bigger context, carefully try to understand the forces that influence the project to balance the quality attributes in a sensible way. We will discuss this in more detail in the next post.

Summing up

In this post we discussed that quality always lives in a larger contexts that affect the different quality attributes. Thus, quality cannot be seen in isolation but always needs to be discussed with respect to the given contexts.

In the next and last post of this blog series, we will discuss that as a consequence of the previous observations quality needs to be balanced on multiple levels. We will also discuss that it temporarily can be okay to compromise quality to reach a more important goal. Finally, we will discuss that just looking at what you do not want (e.g., bugs) does not necessarily lead to quality.

Stay tuned … ;)

  1. This is also true for product development. You also need to balance time, budget, scope and quality in a product development context. The decisions may vary, but the challenge is the same. ↩︎

  2. Today, you would rather write “adding more people to a late software project makes it later”. At the time when Brooks made the observation which resulted in the “law” named after him, gender-neutral language was not yet common. ↩︎

  3. Of course, nobody officially commands to cut quality. Quite the opposite: Everyone demands “high quality” and emphasizes how important “quality” is (without further qualifying it) – and complains that IT sadly did not meet the quality standards they expect in the past. Yet, the decisions made speak a different language. ↩︎

  4. The risk that product managers or other people try to cut development related quality attributes to increase scope or reduce time or budget is somewhat lower in product development (without projects) as the decision makers will be confronted with the consequences of their decisions. They cannot escape them as they can do in projects. Yet, the risk still exists as the consequences do not become apparent immediately. Thus, a clear communication of the consequences of cutting such quality attributes in favor of some other short-term goals is needed to help the decision makers understand what they are doing. ↩︎

  5. For the sake of completeness: The typical counter-argument to this reasoning is: “But what if the company finds the product-market fit and becomes successful? Then you will be screwed without code quality and test coverage. Thus, you need to foster it from the beginning!” I think this argument is wrong for three reasons: First, there is a huge “if” involved. 9 out of 10 startups fail. The odds that you become successful are massively against you. In 9 out of 10 cases, this reasoning just leads to a dead, yet high-quality code base. Second, the reasoning massively reduces the chances being the 1 out of 10: You need at least twice the effort (usually more) to write solid, high-quality code compared to “make it work somehow”. Still, your available budget is fixed. This means, at best you can test half the hypotheses with the money you have. In other words: You just doubled the chance that you fail. Third, if you really should become successful, you will indeed need to rewrite your code base. You will not be able to scale with your trial-and-error, duct-tape code base of the first phase (at least not for a long time). We know that from many startups that have become successful. But that’s also the moment when you a) have the money to build quality in and b) can afford to shift to a different gear. You found the product-market fit. This means, you do not need to validate as many hypotheses as before anymore. Thus, you will have more time to create a solid code base with quality built-in (and you will have to do it to be successful in the longer run). But if you try to build quality in from the very beginning, you most likely will kill the company before you actually need the quality. ↩︎