Technical Debt

We’ve all head this phrase before, we all know it exists, but yet it always seems to be the one thing that all projects carry around. Technical Debt tends to be more apparent in larger, longer running projects but I think it tends to stem from 2 main sources.

Change

As projects continue, more often than not you’ll find that the original assumptions made at the start of a project turn out to be incorrect, or that the system was designed with set requirements in mind but may not suit requirements that will pop up in the future.

The other thing that adds to “change” are phased project implementations. It’s implementing a core system that will have future features implemented.

Technology

Technology is the other key to technical debt. I know that the software I write now is massively different to the software I wrote 3-4 years ago. Dependency Injection, Linq, Entity Framework, Unit Testing, Mock Frameworks, Continual Integration, the list just goes on. The problem is that retrofitting some of these new technologies that can help to make your development efforts more productive, more testable and everything else costs time and money.

In addition to this, larger technology shifts like Windows Forms –> WPF/Silverlight are often not feasible.

Mitigation

I’ve read a lot of articles about how to reduce the risk of technical debt, and a lot of it is focused around Agile. “Embrace Change”. Well, this is all well and good, but there are still issues with this. The assumption is that the system(s) were developed in the first place with a full suit of unit test, encapsulation and everything else you can imagine to reduce the risk of change. The simple fact is that this very rarely happens.

The other end of this is the cost. Any project that will help to reduce technical debt needs to factor this work in, and unfortunately, it’s one of the first things dropped from a project because of time/cost constraints. Businesses just don’t care about it, as long as the application continues to run.

So, my question is, how else can you deal with Technical Debt in a way that has little cost on business?