Technical Debt is a fantastic concept developed by Ward Cunningham in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. You can think of the concept as doing things the quick and dirty way which in the long run sets up the solution to have ongoing technical debt, which over time will come in the form of extra effort that is required in future development.The concept also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity, developers may incur technical debt to hit an important deadline. The all too common problem is that development organisations let their debt get out of control and spend most of their future development paying for this.

So what architectural design ideas would help to minimize the accrual of technical debt? Perhaps a modular approach to adding future functionality, like snapping on Lego blocks approach?

To date there hasn’t been a software development project that I’ve participated in that hasn’t accrued technical debt.

To change code easily, developers need to understand what they are actually looking at so they can find what needs to be changed. To allows them to produce and maintain Clean Code, it is necessary to do continuous clean-up, known as Refactoring. The key word here is ‘continuous’ – not ‘every once in awhile.’ The code itself can’t tell you what design decisions were made and why they were made. It can’t tell you what the logical groupings of entities into modules are. At the very least, there should be comments embedded in the code to help developers understand what is going on.

Experience shows us that once the amount of dirty code gets too big, it is very hard to clean it all up. Test Driven Development, Coverage Testing and Refactoring are intricately linked.

We need to ensure that our customers are aware of their Technical Debt and the long term cost of carrying this debt has on their solution. We need to deal with both legacy and new code and you shouldn’t be afraid to rewrite code. It can be scary to do so, but the benefits can be huge. Even if the end result isn’t any better, you at least didn’t blindly leave it as a mess and will have a better understanding. Try to rotate the refactoring amongst your developers on the team, they then start to understand the pain of not originally being willing to rewrite code.