Code Quality
Jakob Jenkov |
I have worked as a developer since 1998, and learned tips and tricks for code quality in university before that, and kept up with the development in various books and articles since then. Through that I initially got the following two impressions about code quality:
- High code quality is important as it makes the code less error prone and easier to maintain. Thus, paying for code quality upfront saves you money in the long term.
- High code quality is mostly a matter of developer skill and discipline.
However, around 15 years of experience I started noticing some things in relation to software quality, and it turned out that many of my colleagues with about the same experience were starting to notice them too:
- All code eventually decays and becomes worse in quality.
- Code quality is costly to maintain.
- Certain aspects of code quality seemed to not be as important as claimed in the literature.
Once we started noticing the above points, and we discussed them, I started changing my attitude towards software quality and particularly code quality, and have come up with a different model that I believe is better suited for how software development really looks in many, larger organizations. I will explain that model later in this code quality tutorial, but first, let me dive a bit deeper into the background for my "discovery".
Code Quality in Large Organizations
Most of my active career I have worked as a consultant - and as a consultant I have participated in software development in several different, larger organizations. From this work I noticed the following two points:
- The software quality was often lower than what I had expected from these organizations.
- The organizations were still able to release software that was functioning correctly, and they were still making money.
Having seen this pattern enough places, I started thinking about why that was the case. How they were still able to ship software and make money, even with lower-than-expected code quality.
All Software Eventually Decays
The first thing I tried to understand was why the code was of a lower quality than expected. After all, I worked with quite smart and disciplined people in these organizations - so how did the lower quality sneak in anyways?
Quality Standards Change Over Time
The first thing I noticed was, that quality standards change over time. That which we consider good code quality today - we may not consider good quality 5 years from now. For instance, code may be written in an older version of a programming language, and thus does not take advantage of smart features added in later versions of the language. Or - we may even realize that what we assumed was a good way to do design our code - in reality had a lot of bad side effects.
Changing quality standards means, that a code base that is untouched for a longer period of time (years) eventually "decays" in perceived quality. But even if the project is still being actively developed, it may not be kept up-to-date with the changing quality standards, as I explain in the next section.
Large Code Bases
As the code base for a project grows larger, the cost of upgrading to newer language features grows. Imagine you upgrade to a newer version of your programming language (or some toolkit etc.) and you realize that it has a new feature that you could benefit from in hundreds of places in your code base. Your code is working correctly according to the specification. Do you upgrade?
The larger the code base is, the higher the probability is that you do not systematically upgrade the code base to take advantage of new language or toolkit features. Thus, the larger the code base of an actively developed project is, the lower the probability is of the code base being systematically upgraded to keep up with the latest changes in quality standards and features.
Developer Turnover
The third thing I noticed was, that on larger projects there can be a high developer turnover. Developers leave the organization and are replaced with new developers. The new developers may not yet know the quality standards in use in their new organization, and may thus sometimes not abide perfectly by it. The higher the developer turnover, the larger this problem may be.
Subjectivity
The fourth thing I noticed was, that people seem to have subjective opinions of what constitutes high quality code. For instance, some people think functional programming is elegant, less error prone and easily readable. Others think that functional programming is hard to read, hard to refactor and creates a design mess where state and functions are separated. Some people like dependency injection. Others don't like it. Some people like event driven architecture. Other people don't.
Since some part of perceived code quality is driven by personal preference, it is hard to have a team that all agree to the perceived level of quality of the code. Especially when we add aging effects (changed quality criteria over time) and developer turnover (new people means new quality standards).
//// new header...Code Quality Decay Summary
As I have argued above, all code tends to decay in quality over time - even with a great team tending to the code base. That is why you will often see variation in code quality in older code bases. Perhaps it is even inevitable.
Still Profitable Despite Low Code Quality
It is often claimed that a low software quality will eventually harm the company bottom line. However, in my experience the quality has to be really low before that happens - or at least happens in a way where the connection is clearly visible. In fact, the software has to function so poorly that it has a very direct effect on either the company itself, or its customers.
You may argue, that if the software quality is lower than that of its competitors, a company may still be harmed by lower software quality. That is theoretically true. However, I have seen many cases where that seemed to be the case - without it seemingly having any influence on the company's immediate competitiveness. It seems that there are enough other factors affecting competitiveness that a so-so software quality isn't the biggest detractor.
How High Code Quality Do You Need?
Realizing that it is very hard to keep a top nudge code quality at all times, and that it is still possible to make money even if you have a medium code quality, the question emerges:
How high quality do you actually need?
Clearly, if you have too low quality, eventually your software will harm your business more than it helps. But it seems there is some upper level above which the benefit of higher quality may be somewhat limited. So - what is the "optimal" quality level?
What Kind of Quality do You Need?
To figure out what level of code quality we need, I believe we need to first look at what kind of code quality we need. Code quality can be divided into the following categories:
- Correctness
- Testability
- Evolvability
- Readability
- Changeability
- Testability
- Deployability
- Performance
- Availability
- Reliability
- Durability
- Fault Tolerance
- Resilience
...
Code quality is an important part of overall software quality - which is again an important part of software development. When we talk about code quality we are typically referring to specific characteristics of the code. While each person or organization may have their own set of characteristics they consider part of code quality, there are some general characteristics that are often relevant across organizations.
Creating and maintaining a high level of quality in your software's code, user interface, APIs, documentation etc. requires a significant investment in terms of time - and thereby money. Time - first to learn the techniques available to improve software quality - and second to implement the techniques in your code.
This investment is continuous. What is considered "good quality" today may not be considered good quality a year from now. To keep your software quality high you must continuously study software quality techniques and apply them.
- Code quality is not free
- Code decays
- How high quality do you need?
A Different Approach to Code Quality
Because the investment in software quality is continuous, the cost of keeping a high quality can run quite high over time.
B
Creating and maintaining a high level of quality in your code requires a significant investment in time - and thereby money - to first learn how to improve code quality, and
If you have followed the evolution in advice for code quality - much of which has been collected in the book "Clean Code" - you might get the impression that the quality of code
| Tweet | |
Jakob Jenkov | |
