Thanks to Cory House who has released a new Pluralsight course called “Architecting Applications for the Real World in .NET” – I recommend watching it even if you don’t code in .NET

In this course he covers technical debt and makes a point that I knew but had never seen any anyone else make before; that taking on technical debt can sometimes be a good move!

The concept of technical debt is an analogy to real world debt. It was coined by Ward Cunningham and become an increasingly popular and term in recent years. It has helped explain code problems in terms that business people can understand.

There are numerous practices and lack of practices that be viewed as taking on technical debt. Correcting those bad practices by refactoring or implementing best practices is known as paying off the debt.

In the real world, having zero technical debt is rarely achievable, just like have zero actual debt is – there are mortgages, overdrafts and other loans that may be a good thing for you or your company at least in the short term. It all depends on the context: What is the interest rate? Is there a better loan available on offer? When will I need to pay it back? Will I be able to afford to pay it back? How much will I end up paying back in total? Do I really need to borrow? How long would it take before I could afford to buy what I need by self financing?

However we have seen in recent years that taking on too much debt can be disasterous not just for the individuals taking on the debt but for companies, and the wider world.

In software engineering, there is generally far too much technical debt, and although there is more awareness than in the past there are still far too many companies that don’t understand or appreciate it. These are the companies that are paying interest on the interest on their old legacy systems and have getting to the stage where the only option left is a complete rewrite of the system. It is at this point that the amount of technical debt becomes tangible for the company: millions of dollars and perhaps years of work on the replacement system. These “grand redesign” projects are very risky and have a high rate of failure. If the project fails, the company may need to go bankrupt.

This situation can be avoided by managing our technical debt better. I will be covering some specific examples in future blog posts

Further Reading

http://en.wikipedia.org/wiki/Technical_debt
http://www.ontechnicaldebt.com/
http://pluralsight.com/training/courses/TableOfContents?courseName=architecting-applications-dotnet