Res Technicum

Synopsis: Why servicing Technical Debt remains a reactive process

Spoiler: Because it is not important until it is IMPORTANT!

In a perfect world, servicing Technical Debt would be a proactive, ongoing endeavour.  However, in a developer’s world, technical interest payments rarely get made unless there is a looming issue that requires immediate attention.

Technical Debt is a bit like a blister.  It is easy to ignore when it first appears, but the longer you hike without tending it, the worse it gets.  And, at some point, it will require immediate attention.  Best to address the issue early on.

That having been said, it doesn’t usually appear on the ol’ corporate radar until some critical functionality begins to suffer.

There is no question that tactical short-term Technical Debt is a necessary part of a software company’s arsenal.  In fact, I would argue that it can actually be a beneficial component: leveraged properly, it can provide a competitive advantage and allow you to bring software to market quickly.  In contrast, a strategy that consistently incurs Technical debt will bleed your development resources dry.

Enough digression…

A development team is almost always aware of long-term Technical Debt because it works with the nuts and bolts of its company’s technology and software everyday.  However, as a developer, recognizing the fact that your Technical Debt is growing does not easily translate into the servicing of it.  In my experience, here is why:

1. If the company has been around for more than a few years, tackling your Technical Debt is usually a large scope project. If you have large amounts of Technical Debt, the interest payments are going to be painful!  Nobody wants lots of pain.
2. There is rarely an effective way for developers to communicate the problem to somebody (i.e. a decision maker) when that person’s primary concerns are product delivery and/or selling the latest and greatest. (Not to mention that communicating the issue may be construed as simply whining or complaining)
3. Within an organization, Technical Debt is difficult to pinpoint.  The reasons for Technical Debt are complicated and nebulous.  If it were as simple as updating versions of the Database or swapping component ‘A’ for component ‘B’, the developers would already have done so without even broaching the issue.
4. It is difficult for decision makers to quantify the issue in dollars and cents.  If you could prove, definitively, that by not refactoring a chunk of code to leverage newer/better technology it would cost $100,000 over the next 2 years, there would be an Agile Story in the very next Sprint to rectify the problem!
5. In a fast-paced software development environment, it is extremely rare to have the luxury of the time to reduce previously incurred debt without sacrificing something else.  This is especially true in environments that utilize Agile development methodologies or Outsource. (see 6 and 7) As I was recently informed, “If you aren’t moving forward, you are being left behind.”
6. The best way to proactively keep Technical Debt under control in an Agile environment is unclear.  Ideally, the developers would have enough influence to ensure that Technical Debt never gets out of hand, but, in my experience, this is rare.   Besides, what would you do?  Create a recurring task for refactoring?
7. Outsourcing.  It can be very difficult to address your Technical Debt if most of your development resources are outsourced.  I don’t believe, as some of my colleagues do, that Outsourcing only causes problems.  Most of the issues with Outsourcing have more to do with the way it is utilized rather than with outsourcing, itself.  A discussion of the pros and cons of Outsourcing is beyond the scope of this text. That being said, Outsourcing does contribute to Technical Debt morass.  It adds another layer of complexity to an already complex situation.
   1. Agile methodologies and/or outsourcing can be highly successful when applied to creating new products and for new development in general, however, I have not often seen them applied successfully to reducing Technical Debt.
8. There is no short-term incentive for improving existing code.  If you were a project manager or developer, would you jeopardize your bonus to refactor a functional product instead of completing new projects?  For sure, part of the problem is that the project/product schedule is usually created by people who get rewarded for new product delivery and increased sales.  I’ve never seen a bonus delivered for long-term quality of software.
9. “Refactoring” is a dirty word.
10. ??

Some nice articles on the subject:

http://en.wikipedia.org/wiki/Technical_debt

http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx

http://www.zdnet.com/blog/btl/is-your-software-vendor-retiring-its-technical-debt/63393