I was shocked to find out the statistics about the quality of code. I ran into this document which claims it is estimated that there are about 100 billion lines of production code worldwide. As much as 80% of it is unstructured, patched and poorly documented. I have seen, been responsible for and have contributed to poor code in my life as a developer, and therefore I have very little doubt that this shocking statistic may actually be true.

In my opinion, the maintainability of code equals the quality of code. If the code is unstructured or patched, this leads me to believe that it is difficult to maintain. A bold conclusion indeed, and something that makes us software developers look bad. Very bad! I have lived and professionally coded in the US, Europe, Africa and the Middle East and now in South-East Asia so I also feel qualified to say that poor code quality is not limited to any geographical boundaries.

Historically, we have the following definitions of software quality.

• Functional software quality combines the low defect rates with high levels of user satisfaction while meeting all the requirements.
• Structural software quality is exhibited through a robust architecture and well-structured code. Source code with low complexity.
• Aesthetic software quality is measured through aesthetically pleasing with elegant and easy to use interfaces.

Realistically the most important of these is delivering a great user experience. Producing engaging software that solves the user’s problem in an elegant fashion and gives the user the idea that he is in full control is the goal of every team. It is however not that easy – all these definitions have in common that the software needs to be reliable, available and most importantly free of bugs.

Why code quality matters?

Source code quality is the foundation of quality software, for the simple reason that the number of defects is directly related to the quality of the code (Software quality in 2012). More interestingly, it has also been proven that good quality results are proportionate to the success rate of the software project. More than 90% of the projects of high quality result in success while only 25% of the projects of poor quality can be defined as successful. Furthermore, a low-quality code is more expensive to maintain in the long run and will surpass the cost of a high-quality project at the end of the coding phase. Also, high code quality will contribute to the sense of collective ownership.

How to end up in the other 20%?

In order to find out in which group you fall you need to start measuring. Software metrics generally receive negative criticism due to the fact that people approach them as an exact science. An often used argument against monitoring metrics would be to choose to write code for performance rather than maintainability. Unless you are writing a high-throughput real-time system where timing is mission critical, choose maintainability over performance. Adding an extra computing instance in the cloud is cheaper on a monthly basis than an hour of development time in many parts of the world. Various studies on developers have pointed out that between 20 to 80 percent of the time of a developer is spent understanding other people’s code. You do the math.

I am not claiming that monitoring software metrics is the Holy Grail. However, a basic chore like monitoring your metrics and keeping them above adequate standards can greatly reduce your cost of your maintenance. It can increase the chance of success of your software project and it will increase the shelf life of your software. And on top of that it will also reduce risk—you will not be dependent on that single rock-star developer that only knows the intrinsic details of your hard to maintain a system.

Please leave your comments below and share this post!