Technical Debt
Accidental Technical Debt

Continuing from last week’s post on temporal technical debt I want to continue the discussion by talking about Accidental Technical Debt.

Accidental technical debt is when you make a poor decision simply because you don’t know any better.

Classic cases of this kind of technical debt occur when a developer writes code to do a task “the hard way” when the existing framework provides a better approach. Here are two examples from the world of .NET.

XML Parsing

While working on a project that needed to consume information provided in an Xml file, I discovered that the parsing code had been written in this style:

var name = string.Empty ;
var nameAttribute = element.Attribute("name");
if (nameAttribute != null)
{
    name = nameAttribute.Value;
}

int? age = null;
var ageAttribute = element.Attribute("age");
if (ageAttribute != null)
{
    age = int.Parse(ageAttribute.Value);
}

DateTime? birthDate;
var birthAttribute = element.Attribute("birthdate");
if (birthAttribute != null)
{
    birthDate = DateTime.ParseExact(birthAttribute.Value, "o", CultureInfo.InvariantCulture);
}

This is good, functional, working code that exhibits accidental technical debt because the .NET Framework contains a much easier way to achieve the same results - in this case, in the form of a series of smart casts from XAttribute to the common base types.

var name = (string)element.Attribute("name");
var age = (int?)element.Attribute("age");
var birthDate = (DateTime?)element.Attribute("birthdate");

HTML Generation

Another project had a need to generate HTML formatted emails to summarize the results of each completed batch during processing.

We very nearly started writing a set of helper methods to facilitate the HTML generation as a series of strings in C# code.

This would have been a straightforward case of reinventing the wheel - there are already good open source HTML DOM libraries with licenses we could have easily used.

However, even that would have been a form of accidental technical debt, as we quickly realized when we learnt about the (then new) Razor templating engine.

Not only did the Razor engine gave us a way to avoid writing large chunks of hard to read code, it allowed us to store the email templates outside our deployed assemblies, allowing us to quickly revise the templates without needing a new release of the software when we did so.

Management of Accidental Technical Debt

There are three key approaches to the management of accidental technical debt that you need to adopt: maintenance of awareness, avoidance of work and speed of remedy.

Maintenance of awareness - you need to stay up to date with the ongoing evolution of the platform you use, any dependencies you adopt and of the industry in general. Being aware of new releases is a minimal baseline - subscribe to the appropriate mailing list or RSS feed and make sure you at least skim the headlines. Find the channels used to evangelize changes and ensure that someone has the responsibility of staying current. The above example of the Razor engine an example of this - knowing that the engine existed was key to discovering that it was applicable to our email feature.

Avoidance of work - too often accidental technical debt accrues because the developer involved leaps into the job of writing the code before looking for alternatives. Writing new code isn’t always the best solution, especially when the problem you’re solving is one that others will have solved before. The above example of Xml attribute processing is illustrative of this - the designers of the library recognized that extracting values from the Xml DOM was going to be a very regular task and they built in support to do it easily. If the task you want to do might have commonly been done before, take the time to look for code you can reuse.

Speed of remedy - once you’ve discovered some accidental technical debt in your system, what do you do? The first thing it to include it in your backlog of tasks so that the need for a fix is properly tracked. Then, it’s like any technical debt - schedule the appropriate fixes in with other work, finding a balance between business and technical needs. Like all technical debt, the longer you leave it in place, the more it costs you.