There is code which is well tested, well re-factored and built to last. There is also code which is planned to be thrown away in a few days. Between these two extremes, there is a lot of gray area. The code in this gray area is written with the presumption that it would be cleaned up later, but then it is never done.
William Pietri analysed the cost associated with code from the viewpoint of a developer and a business person. According to William, code can be categorized into 3 broad categories.
- Temporary - Code written with a plan to throw away in a short duration of time.
- Sustainable - Code that’s built to last. Well factored, well understood by the team. It has strong automated tests and is not difficult to maintain.
- Half-assed - Everything in the middle. Quick fixes that are never fixed and become permanent. Rush jobs.
William suggested that there is an interesting part in the story. This is the difference in perception between developers and business people on the cost associated with the code. He gave the following comparison for associated cost
| businessperson | developer | |
|
Temporary |
low |
low |
|
Sustainable |
high |
medium |
|
Half-assed |
medium |
high |
Hence, the stakeholders are mostly happy with a half-assed option as it does not cost much and still delivers the value that they are looking for. This is where there is a huge mistake. According to William a better way to compare the code is by looking at the short term and long term costs irrespective of the role. According to him,
| short-term costs | long-term costs | |
| Temporary |
low |
low |
|
Sustainable |
high |
medium |
|
Half-assed |
medium |
high |
The half-assed code eventually costs a lot higher and is detrimental to the business. On the other hand though the sustainable code might seem to be expensive at the start but eventually it is inexpensive over a longer run.
Of course, that’s not just bad for the developers. It’s bad for the company as a whole. If a company’s costs for software continuously increase, that eventually becomes a powerful advantage for competitors who are more thoughtful and disciplined about their approach to software development.
Commenting on the 3 categories, Alex Chaffee suggested that in his view Sustainable code = tests + half-assed code + refactoring. Likewise Chris Sterling agreed with William and commented that
High business expectations + Low engineering push-back = High technical debt which leads to Low engineering performance
Doing a similar analysis, Alberto Gutierrez suggested a different mechanism for looking at code. He rated the code from A to F based on combination of simplicity and extensibility. Simplicity defines the ease of understanding and reading the code. Extensibility defines the ease with which functionality can be added to the existing code. The range A-F defines the extremes between Excellent code and a code which needs to be started all over again.
The analysis again pointed to the fact that the best code would be both simple and extensible. This in turn, would map to the sustainable code category suggested by William.
So, how to avoid being in the gray?
According to William, stakeholder education on the long term implications of the type of code would help teams deliver business value. This would also help the teams avoid the technical debt trap. Once people are educated it would be easier to distinguish sustainable code from the one in the middle.
Most of the projects like that I’ve seen are really half-assed code that got sold as sustainable. Just as dangerous is the cowboy coder who rides in to save the day, but leaves a lot of half-assed code behind for other people to deal with.