Quality

There is a clear order of precedence for code when it comes to quality. It is a) great, b) good, c) none, and then d) weak.

Good code does exactly what people expect it to do, all of the time. It has enough readability and documentation that people can easily figure out what it is going to do. If it needs a simple extension, it is simple to accomplish.

Great code is ‘good’ code that can be used for a variety of different, but similar purposes. It meets the original requirements, but via some configuration can be reused over and over again. 

Obviously, great code would be preferable, but good code is fine too. 

Not having any code is an opportunity to build something new, and to get it done well. It’s also a chance to do some research and determine what types of attributes are necessary in order to meet all of the requirements. If the code won’t compile or is so obviously bad that it never works, then it’s pretty much ‘no code’.

Weak code is the worst. Since it exists there is no incentive to redo the work, but it is often so bad that refactoring it into something better is more time than rewriting it. This covers code that appears to work now but is mysterious, as well as code that mostly works but occasionally doesn’t, and code that will eventually stop working in the future. Spaghetti code is the most common form of weak code, but so are large code ‘piles’, balls of mud, unreadable code, and technically challenging code that ignores theory, replacing it with something so simple and wrong that it could never work properly. 

The cause of a lot of anxiety in programming is a large, badly written system with mostly weak code that is functional enough to work but has a high frequency of failures, say daily, weekly, or even monthly. In these cases, the effort to build the system has been ongoing for years, the stakeholders are very invested in the time and money already spent, but the existence of the system itself is the core obstacle towards getting everything to work. There are just too many weaknesses to be able to redirect the effort towards something viable. But there is too much effort already sunk to be able to abandon it. It becomes a zombie project.

Good and great code can be easily degraded into weak code. It’s far easier than transforming weak code into good code. It usually happens because the original programmers have left, and the new programmers don’t want to follow suit. Weak code in a good system tends to outshine any of the other efforts, enough of it will bring everything else down to its level.