The Software Quality Cost Myth

Software Quality: Not only working software, but also well-crafted software

A short story

Just like every other myth, there is a scary story behind it. The story in this case is this software project that a certain company started. After months of thinking and planning, the directors of the project finally got the budget to kick off. They started hiring people to begin with this business idea that will make them millionaires.

At the beginning, there were only a few people there, and like every beginning, this was a sweet phase. Everybody was happy and extremely motivated. All the members of the team were on the same page, the developers started to deliver the first features and the managers could start showing everybody the first steps of their little baby.

But as the time passed by, and more people were added to the project, the communication between all the team members decreased a bit. The old people are still the same, but the new people… you know, it is not the same feeling. They don’t fully understand the product, don’t understand the code, and they don’t understand certain decisions we made in the past. But there is no need to worry about it, let’s give them some time, they will be aligned soon.

Soon after, the productivity of the team started to slow down, now everybody in the company noticed it. Maybe it was because of the new people or maybe because of other reasons, but the business could not meet the goals set for this quarter. The development team didn’t identify any major problem, so let’s give them a bit more time, and for the next quarter and let’s add more resources there.

Next quarter was even worse, we doubled the resources in the development team, and the productivity dropped to minimums. The development team is delivering nearly nothing at the moment, and the few things they deliver are full of bugs that need endless extra hours to be fixed. They just complain about the codebase, apparently it is a complete disaster now. People are not happy anymore, they have endless discussions about silly things and sometimes they even have heavy arguments. But this is not all, the cherry of the cake is that the two most experienced developers, the ones that knew more about the product, just left the company. And being honest, I think other people are looking for other options outside the company too.

We don’t know what happened, we didn’t do anything wrong. We were doing all good and we were all happy but all the sudden everything was a mess. We still have a business to run, but the software is not there. The developers are unable to deliver anything on time, plus we are all sweating bullets every time we release anything to production because it has lots of bugs. Our customers are complaining a lot because of that and many of them are already considering other options. We lost completely the innovative DNA that helped us to found this company, we are just average now.

If you have been working in the software industry for a while, most probably you have seen or heard a story similar. Maybe not that dramatic ending, but the rest sounds familiar.

What went wrong in the case company or in other similar companies? Why one day they wake up and discover the scary truth that everything was a mess? Well, there are several factors, many. Starting because every company was different, with different context, and the problem described affected at different degrees… But they all share the common cause: low quality software.

In this business case, just like every similar case, the development team was focused on delivering business features, adding business value but they completely forgot all the technical practices. Little by little they were adding technical debt to the project in order to deliver features on time, and just like quicksands, the more they developed, the more they were slowing down. In these cases, adding more people to the project is even worse, because there is more people adding cr*p things to the pile, making the mud snow ball bigger faster.

Don’t think this only happens in old fashioned waterfall projects, this happens also, and even more frequently I’d say, in agile projects. In waterfall projects, may be erroneous, but at least you have everything designed at the beginning of the project. In agile often we confuse no big design upfront with not thinking at all. In the case above, maybe they were using some agile implementation like kanban or scrum, probably they were even doing daily standups, sprint plans, reviews and retros, as they should, but the technical disciplines just weren’t there. Agile doesn’t solve problems, agile exposes problems so you can react to them.

Some symptoms of low quality software, to name a few, are:

No tests or not enough tests
No reliable tests
No automatic tests
No documentation (class diagrams, architectural diagrams, sequence diagrams,…)
Software complex to install, compile or run
Takes ages to be deployed (and it’s all manual)
Has bugs or known issues
Code hard to understand
Expensive to maintain or extend
Software fragile, not stable or not available
…

If you identify any of these symptoms on your project, start to worry but don’t panic yet. Prepare a contingency and recovery plan asap. The later you fix these problems, the more expensive is going to be. In a software project, the pace of the business is set by the developers not by the business, the business can only go as fast as the developers go. The software quality matters and it is something everybody in the project should care or enable.

What is Quality in software?

Well, just as any other product, we have on one side functional quality, which is what we expect from a working product, and on the other side, the structural quality, which is how the product is built. The difference with other industries is that in software you can have the first without the second.

A basketball ball should be spheric and have a certain size, orange and with some black stripes, but if it breaks after bouncing it 15 or 20 times, we can say the quality is very low. The same happens with software, we can have an application that does something as expected, but internally is rot. As long as we never have to change it, there is no problem, but in the moment we have to change anything, then all kinds of problems arise. But being honest, how many projects do you know that developers don’t ever touch the code?

The software quality myth

Quality is always perceived as something expensive, we often say that it is impossible to have speed and good quality at the same time. But in software it’s not the case, it’s something counter-intuitive, because the only thing that can guarantee in your project the speed and flexibility is this high quality in software. Let’s see this in some plots:

When starting a project having low quality, immediately we can deliver business value. At the beginning, there aren’t many problems, as we have only few developers and the code is still small and the functionalities reduced.

But after a while, as the codebase grows and especially, when we add more people to the project, the velocity starts to slow down. The code is not easy to understand, there are different coding styles. Only the authors of each piece of code can work effectively with each part but not the rest because they don’t understand. Gradually and as the time passes by, the team is becoming slower and slower.

But what happens with high quality software? At the beginning, there is not much value delivered because all the technical concerns are set properly. We focus purely on the technical aspects here, business value is a secondary priority at this moment. Thinking how we are going to build the software and also how we are going to deliver it.

The complexity in the design is higher but it compensates with the simplicity in the code. It takes a while until it starts to pay off, but as you see in the image, the velocity by then is increasing much faster than it never did. How step this line will be determined on how good is our design and architecture. As it can be seen in the image, at some point, there is an intersection where low and high quality cross. Don’t think when this happens is measured in the scale of years or months, we are talking about 4 to 8 weeks most probably for this to happen in most of the cases.

If we extend the timeline a bit more, we see that the low quality project is not only not improving, it is steadily decreasing. On the other side, high quality software is able to not just keep the increment of velocity of value delivered, it has even increased. One reason is because if we have a good design, we can start reusing pieces of code after a while. The second is that we can add more people to the project and they are more productive as they understand the code. It means increasing the team, proportionally increases the velocity. When the quality is low, new joiners have to ask questions for several months, slowing down, not just them but the other person that helps them.

Good quality practices.

There are tons of literature written about best practices when writing code, but if you don’t know where to start, I would recommend you taking a look to the extreme programming (XP) practices:

Extreme programming is a set of well proved practices introduced by Kent Beck back in 1996. It is probably the most used framework in combination with some agile processes like scrum or kanban. It focuses on raising the internal quality of the software product and delivering value continuously to the business in short iterations. Give it a try.

Summing up, quality in software is extremely important and sadly, it is something usually overlooked or directly forgotten. Counter-intuitively, high quality in software is the key to have fast deliverable and flexible software products. Good practices, just like every other practice, requires some time of learning. It is like learning how to ride a bicycle or a car, or even a musical instrument. It requires some dedication and discipline to become competent at it. The good part is once you get it, you have it forever. You can bring that knowledge from one project to another, just as you would do when changing the bicycle, the car, the guitar or the piano.

Thank you for reading all the way until here! If you want to comment this post you can do it on medium.com or dev.to.