Plastering over the cracks of technical debt in software development

This Computer Weekly Developer Network blog is a guest post written by Michael Vessey, a senior consultant with software quality provider SQS.

If you do just enough to keep your car running — i.e. you just check the oil and tyre pressures but never take it in for a proper service — eventually, something bad will happen and your car will break down or become very expensive to run.

Similarly, with Agile methodologies like SCRUM, if you only ever do ‘just enough’ to build software that is ready for market, you are probably building up a technical debt that will need to be paid.

What is technical debt?

Technical debt is not a new idea in computing circles; it does however seem to have come into fashion lately. To understand technical debt better, consider how your house may have been affected by the high winds across most of the United Kingdom in January. Many houses may have suffered structural damage such as cracked brickwork and fallen chimneys due to structural movement. Let’s consider these cracks as technical debt; the building still performs its intended purpose, however we know we will have to fix them at some point

The right thing to do is to have the damage inspected and the structure of the building repaired before any damage spreads and the cost of repair increases. Instead, if we often chose to cover over the ugly cracks and render the outside of the house so that we lose all visibility of how the cracks are developing underneath the rendering.

In 1992 Ward Cunningham summarised this issue for software engineers:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

With more and more companies switching development from traditional waterfall methods to Agile and SCRUM we are seeing development team leads focusing more intensely on technical debt.

The main benefit of Agile to these companies is that you can release small portions of the product at early stages of the lifecycle by doing “just enough” to get the component ready for market.

But — by doing “just enough”, the risk of technical debt is increased.

Static analysis can help development leads monitor some aspects of technical debt. Microsoft has recognised this and incorporates static analysis in its development tools. It is incredibly easy to run code analysis within Visual Studio 2010, however understanding the results can be more complex.

The results of even a basic code analysis can be very noisy, with lots of warnings making it difficult to spot the most important issues. Even simple sections of code can generate results from a “basic correctness” analysis.

Take the following snippet of designer generated code:

private void InitializeComponent()




// Form1


this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);

this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;

this.ClientSize = new System.Drawing.Size(284, 262);

this.Name = “Form1”;

this.Text = “My First Form”;



The basic correctness rule set throws up the following warning:

Warning – CA1303 : Microsoft.Globalization : Method ‘Form1.InitializeComponent()’ passes a literal string as parameter ‘value’ of a call to ‘Control.Text.set(string)’. Retrieve the following string(s) from a resource table instead

While this is valuable information, it’s all too easy for anyone with the correct knowledge to suppress the warning, hiding it from your automated static analysis. The line of code below will do this.

[System.Diagnostics.CodeAnalysis.SuppressMessage(“Microsoft.Globalization”, “CA1303:Do not pass literals as localized parameters”)]

Some developers might be tempted to ‘paper over the crack’ by suppressing for valid reasons, for example: to focus on other messages, there may be SQL injection warning but the developer seeing the warning is not a SQL developer or there may be an internationalisation issue and the developer is unaware that the company will later be launching a multi-language.

Suppressing warnings does, however introduce two major risks. The first of these is that a developer can choose to hide issues from a code inspection, the second is that the scope of the suppression does not extend to just a single line of code.

If a new instance of the same warning is introduced into the same section of code then you have two instances of technical debt and yet no new warnings; new cracks can appear and you would not be aware of them because they are hidden beneath the paper.

When managing technical debt issues in code, just as with cracks beneath the rendering of a house, we need to carefully consider the implications before suppressing errors. If we fail to take the proper steps and care, we won’t know the extent of the problem — until something as disastrous as a wall falling down occurs.

These tools are provided for a reason. Make sure you don’t plaster and paper over the cracks and hide your technical debt.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

This post suggests that Agile methodologies are oriented towards delivering software with a technical debt. Personally I find it hard to agree with this statement, as to me delivering working software implies delivering high quality software, particularly if we think with a long term perspective. In my experience developers put a greater emphasis on quality when working with an Agile method, than with a waterfall or any other method. I believe the focus of Agile development is producing high-quality software in a time frame that maximises its value to the business. With the traditional approach to development, there were always particular people responsible for testing or quality assurance, whereas with the Agile method the whole team feels responsible for quality: everyone is testing and at many stages too. If we talk about code analysis, I cannot imagine developers suppressing errors or non-understandable code or that their goal is simply to sweep these under the carpet - this would certainly never happen at my company. Besides, with quality processes this should not be possible: code is passed not by one person alone, but by the whole team. Further, there is always more than one stage at which code must passed. Static code analysis tools should also be integrated with continuous integration, giving instant information about the health of the code. But the static analysis is just one stage in the process. Agile retrospectives gives developers opportunities to improve it all the time, iteratively. For example, in my teams, if we know that we failed because of something, we perform a root cause analysis and remove the issue, or simply improve our way of developing software. Close co-operation with the end-client, a strong project manager and passionate developers also have an important role to play in ensuring quality, Agile-developed code. For example, if you have developers you can trust and quality is part of your organisation's culture, then you do not have to worry about a technical debt buried somewhere in your code. If we compare traditional methodologies of software development with Agile, I think you find that with the traditional approach you have even greater technical dept but it is hidden for a long time - because the software must wait for all development phases to be completed and before it is delivered to testing. This can be a huge gap. We should remember that in many cases there is not enough time for testing or no time for fixing issues, and at worst this results in not delivering the right product. With Agile this gap is much shorter: early test, early deliver and the client has plenty of opportunity to check his expectations against what is actually being delivered. Of course Agile methodologies do not solve all our problems always. In some projects Agile would not be the best choice, but I don't believe that Agile methodoliges lead to a culture of technical debt.