The Inquisitive Coder – Davy Brion's Blog

When it comes to code, a lot of people are often very opinionated. Supercomputers couldn’t even keep track of the number of times i’ve looked at a piece of code and said “this sucks”. We often qualify code as crappy, bad, decent, clean, good, great, whatever else you can think of. The problem is that this usually comes across as a very subjective opinion. What one person might think of as crappy code can be decent or even good to someone else.

I think it would be better if we started talking about quality of code in terms of how healthy the code is. In a very abstract way, software is basically a life form. After its creation, it starts a life of its own. It tries to fulfill its purpose and to do that, it often has to be changed or improved. Depending on how well it was created, it might be capable of easily adapting to whatever is required of it. Sooner or later, the software will reach a point where it can no longer easily adapt, which usually is the beginning of the end of this life form as new software will be prepared to replace it. Ideally, we’d like to keep working software around as long as possible. Not only because of the financial consequences of not doing so, but because we really shouldn’t be redeveloping the same systems over and over again.

To keep working software around for a long time, we have to take care of its health. It’s important to keep it healthy at all times. As soon as rot is introduced in the internals of a piece of software, it either has to be removed as soon as possible, or it will spread and affect other internals. When too many internals are infected, it becomes very hard or even impossible to help the software. Just like humans need to take care of their bodies, it is important that the code of the software is kept in a healthy state.

So when can we say that code is healthy? When it is easy to modify or improve, without affecting other parts of the system in a negative way. How can we achieve healthy code? By keeping it clean, flexible and readable. To many people, that equals good code. To most managers, the term ‘good code’ doesn’t really mean anything. As long as the code makes money, it’s good code for them. But if the code is not healthy, it will stop making money sooner rather than later. Telling them the code is not healthy as opposed to saying it’s bad or crappy or whatever signals a possible business problem instead of simply hearing a developer complain about code he doesn’t like for whatever reason.

Simply put, communicating about code quality in terms of health allows you to focus on what’s really important (the viability of the software) instead of coming across as someone who simply doesn’t like the code because of personal preferences.