Quality - The unknown entity - Part 4

This is the fourth and last post of a blog series discussing quality.

In the previous post we discussed that quality always lives in a larger context which affects the different quality attributes. We also discussed that thus we always need to discuss quality with respect to the given context.

In this final post of the 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.

Quality needs to be balanced

It became apparent in the preceding sections: Quality needs to be balanced.

1. Quality is a complex, multi-dimensional thing. Very often you find conflicting quality goals that you need to balance (e.g., how to balance security and usability). It is not possible to simply maximize all quality attributes at the same time. Therefore, you need to prioritize and find trade-offs with respect to the overall project goals and context.
2. Quality is only one of the four traditional project forces time, budget, scope and quality. A change in one of them always affects at least a second one. Therefore, quality also need to be balanced with respect to the project goals and context. This in turn affects quality with its multiple dimensions inside a project.
3. The project context needs to be taken into account. There are a lot of forces that create pressure on a company and thus on their projects. These forces and the context they create result in different sweet spots and constraints for the different quality attributes, including the measures to implement them.

As a result, a “one size fits all” for quality, its attributes and their implementation does not exist. As written before, a 80% unit test coverage might be a great idea in one situation, while being a bad idea in another situation. 99,9% availability might be a great idea in one situation, while being a bad idea in another situation. And so on.

To be clear: This is neither a call nor an excuse for sloppy development. I often work in enterprise IT contexts. In such contexts, not only runtime quality, but also development time quality, i.e., “code quality” has a huge value and we need to strive (and sometimes fight) for it.

Yet, it is important to understand that even if quality requirements of a certain kind are sensible in most of our assignments, it does not mean it always needs to be that way. We must carefully avoid to fall into the dogma trap. We see people insisting time and again that certain quality attributes they found useful in their projects always need to be maximized – no exceptions admitted.

While such unrelenting positions often are understandable if you look into the individual experiences and sufferings of that person, such positions are not too helpful in general. They can be useful in certain contexts. But a fixed set of quality requirement cannot be useful in all contexts.

Therefore, we always need to understand the company context, the project context and the different stakeholder needs to find a sensible balance between quality and the other needs as well as between the different quality attributes. Based on my experiences, I never have seen two projects with exactly the same quality needs.

Quality sometimes can be compromised – but only temporarily

There are some places where it even makes sense to pay relatively low attention to quality, e.g., in an early startup context or with throwaway prototypes. But most of the time, quality is an equal force and not devoting enough attention to quality will have bad consequences – often already in the short, but definitely in the long run.

Yet, sometimes it makes sense to temporarily prioritize quality lower than usually would be sensible. Remember the example with the 3 months’ window of opportunity before competitors are going to snatch your market share if you do not release your solution within that time frame.

In such a setting, it can be sensible to go with a bit lower quality standards for that time frame. As a consequence, you will accumulate “technical debt” ¹, i.e., places of lower code quality that make further maintenance and evolution harder.

Two things are important in such a situation:

1. Such a reduction of quality below the required standards must be temporary. It must not become the normal state. An agreed upon plan is needed how and when to “pay back” the “debt” (to stick with the metaphor).
2. The effects of the quality reduction must be made explicit. It is important to record where quality is compromised, where corners are cut. Everyone must be able to see the deviation between required and actual quality – ideally including a rough estimation of the costs and effects of not fixing it.

Typically, development time related quality attributes are cut first in such a setting because cutting runtime related quality attributes quickly compromises user experience. The effects of cutting development time related quality attributes like code quality will not become visible immediately.

Therefore, it is important to make the “debt” and its future effects explicit for everyone involved. Otherwise, the risk is high that people simply “forget” that quality has been deliberately compromised to reach a temporarily more important goal. It must be made transparent what it costs over time not to fix the defects. Especially the accumulating effects, that you pay again and again and that one cut corner often leads to another one and another one, must be made visible.

It must become clear that the price of not “paying back” the “debt” will be higher than even the people demanding the quality cuts in the first place are willing or able to pay.

Metrics can help to make the effects of “technical debt” explicit. E.g., good code quality helps to reduce the average change defect rate and average feature lead time. For most companies and projects, it is important to keep both metrics below a given threshold (the exact values might vary between projects). If the “debt” is not “paid back”, those metrics will rise above the desired values – usually sooner than later. Such metrics can support your case.

It is also important to have a schedule in place until when the quality defects will be fixed. Ideally that schedule is created at the time when the temporary quality reduction is decided. There must be an agreement to remove the known defects after the time period with deliberately reduced quality standards ends. Otherwise, you won’t be able to meet the agreed upon quality goals afterwards.

Unfortunately, often IT project teams are pressed to reduce quality standards to achieve some other, temporarily more important goal without an agreement when and how to fix the defects. Here it is important to fight for such an agreement before agreeing to the reduction of quality standards. Otherwise, you end up in a self-enforcing downward spiral of bad quality, commitments not kept and increasing pressure. ²

Overall, it can be said there there are situations when it is sensible to temporarily reduce quality below the normally required standard. It does not make sense to insist in the standard in those situations. Yet, on the other hand it is important that it is an explicit deliberate decision, that the reduction is temporary, and that there is a plan to restore normal quality afterwards.

The widespread “pressing for more features in less time” habit that can be observed in many companies is not such a situation. In such a setting it is important to strive for a sensible and sustainable quality standard. Not seldomly, our clients are not aware that they created such a setting. They just follow a habit that has established over time. It is our job as IT experts to help them understand the consequences of their demands and break the habit also for their own good.

A final note regarding quality

About a year ago, I discussed a short, yet extremely insightful presentation that Dr. Russell Ackoff gave 1994 in a previous blog post.

Russ Ackoff discussed the relation between systems thinking and quality in his presentation. I can highly recommend to watch the presentation. I have rarely seen a presentation with so many insightful gems in such a short time (the whole presentation takes just 12 minutes).

Here I would like to repeat one of the observations Russell Ackoff made as a final thought before wrapping up this little blog series about quality. He said:

A defect is something that’s wrong. When you get rid of something that you don’t want you don’t necessarily get what you do want. And so, finding deficiencies and getting rid of them is not a way of improving the performance of a system.

This observation lead him to a core principle:

Basic principle: An improvement program must be directed at what you want, not at what you don’t want.

This is also relevant for many quality discussions I have seen in IT. We are so often focused on “avoiding X”, being it bugs, poor evolvability, security breaches, or whatever. While it definitely has a value to strive for avoiding these things, their absence does not necessarily mean that we create high quality.

Quality is more than avoiding what you do not want.

We need to look at what we need and what we want when discussing quality. And we need to broaden our view to look at all dimensions of quality (what we usually do not do if we only focus on things we do not want). Otherwise, chances are that we will not achieve high quality – no matter which beholder’s eye we are using to look at it.

Summing up

There would be many more things about quality worth discussing. There is a reason why whole books were written about the topic. The aspects I tried to cover in this blog series were:

1. Quality is in the eye of the beholder – Different people experience different properties as “quality”
2. Quality has many dimensions – Quality is not a simple value, but a combination of many properties
3. Quality needs to be made measurable for a shared understanding – Without making explicit what needs to be fulfilled to which degree, it is impossible to create a shared understanding regarding quality
4. The consequences of demands are often not understood – Most people do not understand how their demands impact quality. We as IT experts need to help them understanding the impact of their demands
5. Conflicting quality attributes – Different quality attributes can be in conflict. It needs to be made explicit which attribute is more important in case of a conflict
6. Quality lives in a context – Quality is just one dimension of a software development project. A project has more, also relevant dimensions that can conflict with quality
7. Projects live in a context, too – Projects live in a company context that affects the projects and quality, too
8. Quality needs to be balanced – Quality is not an end in itself but needs to be carefully balanced with all other, potentially conflicting goals. Also the different quality attributes need to be balanced
9. Quality sometimes can be compromised – There are settings when it is sensible to temporarily go with lower quality. But it needs to be temporary and explicit
10. Quality is more than avoiding what you do not want – Just looking for the absence of something (e.g., bugs) is not quality. Quality must be directed at what you want, not at what you do not want

Even the few aspects I discussed here make it obvious that discussions about quality will not cease to exist. To a certain degree, we actually need them. We need to make the different, sometimes conflicting needs and expectations regarding quality explicit. Otherwise, we cannot create a shared understanding for our context.

But we need to avoid to fall in the “dogma trap” that can be observed in the IT community time and again, if quality becomes an end in itself, if only one interpretation is accepted as “correct”. These types of discussion are not helpful as they mask out the majority of aspects that constitute quality.

I hope this little blog series contained some food for thought – and maybe it provides you with some helpful arguments for your next discussion about quality …