understanding technical debt

Technical Debt is a term coined by Ward Cunningham a very long time ago. Here's a very good video of Ward talking about this metaphor. Martin Fowler has wrote extensively about it as well. Most everyone understands the concept of debt in a financial sense. The idea is simple - much like financial debt where you consciously decide to swap time to market for interest payments (higher maintenance costs). Like much of software development, it's a gamble. It's a gamble that paying this down over time will be cheaper over the long haul given total cost vs. value. If change to this area of the system is unlikely, it's typically a good gamble as you may actually never be required to pay interest. There are other forms of interest payments beyond just maintainence code, but you get the idea.

I love this concept, but I see it abused over and over again. The pivotal word in the above definition is "conscious". The decision must be conscious - i.e. if you don't know you're implementing a feature in a messy or unmaintainable way, then it's not debt. Rather it's probably negligence.

In my experience, there is simply a shortage of people that truly know how to create maintainable, well designed, well factored software. There's a country ton of software developers that know how to hack something together to the point of being functional. There is a difference. And the vast majority of times, it's not even clear how a system should be probably implemented at the beginning of a project. The key is creating software in a manner that can easily evolve as you learn more what the system should do functionality and non-functionality. You must write change-friendly software.

Photo by Blake Richard Verdoorn on Unsplash