Temporary Code, Sustainable Code and Everything in Between

Posted by Vikas Hazrati on Mar 24, 2010

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Delivering Quality ,

Code Analysis ,

Agile

Tags

Quality

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.

 

1. Back to top

   Mark and Review

   by Markus W.

   Usually before a task is completed in our project it has to be reviewed by another developer. Since we don't want to be too pedantic about code style, performance, etc. we decided that it's done as long as the requirements are met and a passing test exists
   (which is also important for the developer to stay successful).
   
   However there are some situations where the code is not ideal and then we are writing "Code Smell" markers an pin them to the wall. The team reviews them from time to time and decides if there is action (e.g. refactoring) required.
   
   I'm also marking code smells when I'm working on existing code, which is good if you don't have a review process.
   
   If you've reached the point when someone in your team tends to name the software as a code smell it's probably too late for improvement ;-)

   Reply

• Older >