The Essence of Quality[1]

“If you’re not sure why it works, you won’t know why it fails.”
(The Pragmatic Programmer, page 201)        

Quality in Software remains as elusive today as it did back in the day when an actual moth in one of the relays was affecting the expected behaviour of the Harvard University computer (September 1945). Interestingly, the process of understanding what might be going on and isolating the actual issue hasn’t changed much since.

However, defining quality in the context of programs, applications, and digital products in general has, as of yet, not being achieved in a convincing and universal way that would allows us to talk in the same language with others and find a common ground faster. Not only is it complex to define, but to understand, and visualize as well.

Is it a reduced number of bugs? The high number of Unit Tests? The low number of customer complains? The number of users we have? The number of transactions? The number of costumers that use our application even if seldomly? The number of lines of code? The complexity or simplicity of the logic in our code? How well or fast people understand our screens? Sadly, to all yes, and to all, not quite.

The thing with Software in general, and now with Services provided through Applications, is that it carries around too many “it depends”. Most physical things have a deterministic side that allows to define them easily.

For example, in food, an organic origin usually implies better quality (and higher cost). Some product brands are known to have better manufacturing controls, processes, use more expensive raw materials. We usually can tell by looks alone, by the touch of the cloth or the solidity of a structure, the precision of the seam, and so on.

Not with Software. There are too many variables into play, too many things happening behind the scenes and in front. In the development processes, in the technology stack, in the how it is done, and many, many more characteristics that make it too complex to just focus on a single, or a few elements and say, “those define our quality”.

All of this wouldn’t be much of a problem if it weren’t because it does cause a lot of inconveniences. And, as the digital product grows and ages, everything does with it, sometimes in an exponential way. This increases costs, time invested, and the need for resources[2]. Can we do something about it? I think so, let’s forget about the glitter and focus on the essence.

Definitions of Software Quality

Before we get too far ahead of ourselves, let’s have a look at some of the most common definitions for Software Quality, this way we can have a better context for the next part of this article.

The American Society for Quality (ASQ) presents us with two approaches to it. One is through Defect Management, the other through defining and working around Attributes.

The International Standards Organization (ISO) focuses on “quality characteristics, or system ‘-ilities,’ i.e. security, reliability, and maintainability”.

The Project Management Institute (PMI), in short, talks about Quality Management and the presence of a managerial process. The Quality Assurance, and a technical process, the Quality Control.

As we can see, the approaches vary more in the naming convention used and the point of view taken than -real- form or content. A digital product might not be physical, but it still exists within the constraints of a physical reality, thus it can be mapped to the processes we use to create anything else. However, this abstraction, this oversimplification, becomes a multi-edged sword with as many potential benefits as it presents drawbacks. We must be mindful of how far we want to, or can, take the analogies.

What Is the Essence of Software Quality?

With everything going on with the Software, around it, within and without as we develop, commercialize and use it. How do we identify the essence? Where do we look? Do we go macro or do we search micro? Do we approach things from the Art front or the Science side? Is it in the coding, the process, the tracking, the testing, the tools, the people, the consumer, the user?

The first level that matters for us, is that developing is about being creative. Every time we gather requirements, write User Stories, test, or code we are figuring out and understanding many levels of abstraction in order to come up with an actionable image, idea, feature, or solution.

The second level is about reproducibility and the formal aspect of the whole activity. Having limited time and resources means that we need to put a scientific frame around our infinitely and easily distracted inventiveness.

At this point we can ask again, where is the essence? Then, we generalize Art and Science to get to the next level. To find the common element. Discover that the spark that drives them both, albeit in different ways toward distinctive goals, is thinking.

Being honest to ourselves, it really boils down to common sense. The more thought we put into anything we develop the less errors, defects, and failures that will be found[3]. This, by the simple fact that we have a better and more complete understanding of what we want to achieve, what we require, what the solution should be like. One great advantage, is that thinking implicitly shrinks the freedom space of creativity, without hampering its innovative aspect.

It is funny how this is a known fact, even if at an instinctual level, maybe a non-formal one. As the following section shows, over the past years what has been happening is a move toward emphasizing, organically, the need for thinking, allowing people to properly grasp the problem, to come up with a better solution. I.e. less assumptions, less extreme freedom to do whatever, a better building block on which to continue growing.

Let's Put Some Thought Into It

Here are some recent attempts at formalizing thinking in Software Development. Alas, since things are usually described in an open and generalized manner, when not in some cryptic sophisticated sounding wording, people tend to interpret them in their own context and point of view or understanding, which can distort the original idea or goal. But, at least we are trying.

Shift Left Testing

What is SLT if not a big wink with a shoulder tap to “let’s think this through as early as possible”? It promotes testing at stages where there is little code done, where the idea is starting to take shape. Where we can think about it in a purer state so that when coding it, we have a better picture of what we are aiming for.

Test Driven Development

TDD is also about going deep on the understanding as early as possible. We think about the tests, we think about the things we want our solution to do, the problem to solve, before we write a single line of it. It is also a great way to give Unit Tests a more formal context and a bigger future value than by writing them after-the-fact. Very good way to setup a frame for the creativity as well.

Agile/Scrum/Kanban

When we analyze Agile and its frameworks, we hear and read a lot about phrases such as “provide the space”, “have the discussion”, “allow for conversation”, “ask the right questions”, “see the big picture”, “detect anomalies”, and so on. These are basically team thinking triggers/ideas and the spoken language (communicating) is our way to deliver and receive them.

We are trying to, somewhat scientifically, push toward thinking, by providing the right context for it. Of course, the moment all becomes routine, or communication can’t happen without too much pull, the whole idea breaks down because there is no proper medium for thinking.

However, There Is a Big Irony

Thinking, obviously, requires time and that is probably the one resource in the industry of which there is never, and will never, be enough. It really is one of those things where “it is what it is” has been written in stone. The best we can do with it is optimize it, manage, or increase the number of resources we have working simultaneously.

The latter being the least liked option since it opens to a world of logistic problems when we talk about large projects, with dozens of teams, or more. There are known limits beyond which adding people only increases the management and coordination part to the point that no extra work is achieved.

Conclusion

At the end, when it comes to Software Development, we can go around it and about it in hundreds of ways. We can copy or adapt what others are doing. We can improve, evolve, and change what is out there, or not. But what we really need, the one simple thing that is required, as with so many other of the current problems Humanity faces, is to “stop… and think”.

In many cases it might not solve everything, in most it doesn’t even do much at the end toward Software Quality itself, but it helps us with being aware of the risks and potential problems, find the best solutions, allow us to keep on moving forward for longer. After all, as Software grows it reaches a point of entropy that, just like our Universe, can’t be avoided and where things simply blow up (in some cases not just metaphorically).

We can postpone the inevitable, we can slow down the process down to a crawl. However, we cannot stop it. We cannot reverse it. We cannot avoid it. It is the same with everything. But for Software, it is visible not in a single lifetime, but in a few years, if not months. The end is near, always there, potentially hiding around the corner of the next merge. So, why not think about it and keep it all in mind?

[1] This article is based on a talk with the same title given at BairesDev as part of the knowledge sharing initiatives of the company (Circles, Tech-Topic, December 7th, 2023).

[2] It is at this point that in many cases we go to the extreme of considering whatever is being done disposable. It becomes relatively simpler, and less of an investment, to start anew than keep an application alive. We reach the extreme were “if it is so broken, why even try to fix it?”. The mobile App industry move with this mindset (or seem to), since working on a completely new version is less complex, and less expensive, than trying to update an old one considering all the changes that happen from year to year at Hardware, Software, and OS level.

[3] We have to keep in mind that this assertion comes with a huge disclaimer and is not “a rule”. Even when we think things through there are so many elements involved that software entropy is inevitable and it affects most products very fast.

***