Quality first ?

Over the last couple of decades, I’ve personally lived many many experiences where having less focus on software quality lead a project, a product, or even a whole company to a harsh failure.

Actually I’m quite sure that everyone reading this article has had similar failure experiences in the past, where poor software quality has caused a huge and an unpredictable damage to the place he worked for.

The accumulation of these negative experiences is probably what lead a large number of software developers and organizations nowadays to believe that quality should always come first, and that professional developers should not negotiate quality under any circumstances.

Actually, just mentioning that quality is a matter of compromise is often taken by some professionals as a sign of immaturity of those who claim it, to the extend that they might even loose a job opportunity if they just state that during an interview.

But is that really the right way to go ? Should we really put quality first ?

Well, to answer this question, I’d like to start from the high level corporate goals...

I’d like to ask a very basic question: What’s the main goal of a corporate ? Why do these corporates exist and why do they do business at all ?

The answer is pretty easy actually: The main goal of any corporate in essence is to make more money, and that’s simply it !

So as long as you’re working for a real business and not a charity organization, your business probably exists mainly to make money. Period.

How can a software business achieve this goal ? What should we as software developers do to make our software worth more money ?

To make more money all what we as developers need to do is to just make our software more “valuable” for our customers. Because the more our software is valuable for them, the more money they’ll be willing to pay for having it.

That should be common sense actually.

So what actually should come first in the software industry (and probably in any industry in general) is the product “value”. And by “value”, I mean the value as perceived by the customer (as he’s the one paying for it), and that is simply what’s called the “Business value”.

In his latest book: “Clean architecture”, Robert C. Martin mentioned that in software development there are two values involved. The behavior/features (i.e. the business) value, and the architecture/ structure (i.e. the technical) value, and he stressed that the architecture (the technical) value is more important than the behavior value and should be given a higher priority by developers along the way.

Although uncle Bob has started his career as a programmer 10 years before I was even born, I dare to completely disagree with his statement above.

In any business, only business value is what matters, and software business is no different in that aspect.

But, in software industry business value comes in two flavors actually:

Short-term business value, which involves the requirements as seen and requested today by stakeholders.

And long-term business value, and that involves longer term requirements which the stakeholders might not mention or even see today but will probably need in the future. Think of stuff like maintainability, scalability, security, etc.

Although that the long-term business value is usually achieved by focusing more on the technical aspects of the solution (good architecture, clean code, nice patterns, etc.), tackling these aspects from a business perspective as a "long-term business value" will greatly help developers in setting their priorities and deciding on what really matters and what doesn’t necessarily matter, even if it seems to be very valuable from a technical point of view.

For example, a poorly written piece of code might be very attractive for developers to refactor immediately if they believe in the existence of a “technical” value thing, and even worse if they’re giving it a higher priority than business value.

However, if refactoring is seen by developers as a long-term “business” value, then they will probably start asking: why should we ask our customer to pay us for refactoring this piece ? Is it for maintainability ? Then how frequent do we expect to do maintenance here ? If it’s not that frequent then let’s just keep it as it is and avoid the risks of replacing what’s proven to be working with what we’re hoping that it will be better. Let's just speak business !

So it’s not really quality that should come first, it’s business value actually which should always come first, and should drive every single line of code we write, every decision we make, and every action we take.

But, for our software to be valuable, doesn’t it have to be of good quality anyway? why do we have to compromise quality? And why do we have to discuss at all whether “value” is more important than “quality” or if it’s the other way around ?

Surprisingly, focusing on quality can sometimes (and maybe even often) distracts us from focusing on business value !

And that’s why we need to have this discussion, and to make priorities clear.

What we’ve learned over last years, is that real business value can never be determined or predicted in advance. It always comes from a journey of exploration, where the team along with the customer discover through many possible options trying to find what actually matters and what’s actually valuable.

Through that journey everything changes. New features rise, and many features get thrown away. And that’s more or less what we call: agile software development.

The main risk of giving quality a higher priority over business value, is that during that journey of exploration the team might be required to gold plate features which will be thrown away over future iterations, just for the purpose of fulfilling the “quality” constraints imposed by their understanding of priorities.

And that involves many serious risks actually…

- By gold plating features too early, we’re incurring costs which can be found to be unnecessary later on as we proceed further with our exploration journey, when these features get de-scoped, or dramatically changed.

- Even if the company is willing to incur these costs (maybe for the purpose of keeping a good image with their customers), the time spent by the team on gold plating is actually delaying us from getting customer feedback on-time, and therefore delaying discovery of the real business value, and the real competitive advantage of the product and the organization.

- Even worse, software is written more or less by humans, and humans tend to get attached to products they create (the IKEA effect). So when we ask them to put more effort on gold plating a feature, then later on (as we proceed further in our exploration journey) we ask them to throw away what they have just finished and polished to perfection, they will involuntarily try to avoid that change instead of trying to embrace it. And avoiding changes is proven to be seriously harming the overall business value a product can achieve.

- Moreover, setting quality as the number one priority for an organization will dramatically affect the developers' behavior (especially less experienced ones). They will tend to care only about how beautiful their code look like from a technical point of view, and they will completely forget about the business value of what they’re doing. They’ll enjoy pushing more and more technologies and frameworks and useless design patterns to the code, and they’ll get their dopamine shots from investing more time in beautifying what might even makes not value at all from a pure business point of view.

I personally see technical debt as a tool, a powerful tool actually, which can and should be used consciously to maximize both the short and long term business values of a product.

In a true agile culture, a software product is more or less an evolving prototype, and it’s never wise to always deliver high fidelity prototypes, as that will definitely affect our ability to reach a valuable prototype at the end of the journy. While only a valuable prototype is what actually our customer is willing to pay for.

It takes some education and much more experience from a team to be able to decide on the right amount of quality that needs to be maintained in a product throughout its lifecycle in order to be able to reach the maximum business value as the product evolves.

And it takes much effort from organizations to raise a culture where this balance is well maintained, and furthermore more recognized.

With all that said I personally believe that quality is never first.