The term technical debt was first introduced by Ward
Cunningham and is a metaphor to describe the consequences of quick and dirty software architecture and development. It is not necessary a bad thing to fall into technical debt as long as you’re doing a good job at understanding how you’re going to pay it in the future. A quick parallel with financial debt can be made easily: It might be a good idea to get a student loan to get a proper education, but you better plan carefully you repayment if you don’t want to end up in a financial nightmare. Same with software: You might want to cut corners to deliver a cutting edge new feature ahead of the competition which will generate large revenue, but you better plan carefully to polish your code if you don’t want to end up in maintenance nightmare.
Technical debt is all the work you postpone for any given reason:
- We don’t have time to upgrade our compiler version for now, we’ll do it later.
- We should probably use this design but it will takes 6 months compare to this reasonable one which will take 2 months.
- We’re reaching some crash after a 100 hours stress run. No customer will go that far, let’s ship it for now !
- Our code doesn’t comply with industry standard. Let’s ship it anyway and will fix it later.
You definitely know you have technical debt when:
- It takes as long to fix a defects as it takes to implement a new feature.
- The knowledge about the software in debt is in silo and you have only a few people being able to support the code.
- Your customer hit new problem and the limit of the software you’re not able to fix quickly.
- Nobody knows the state of the software.
So what should you do about it ?
- Try not to accumulate too much debt.
- Keep track of your debt. Make sure all bugs and intermediate design are documented. Make sure the debt is highly visible to all within in the organization.
- Make sure you don’t over commit yourself with impossible deadline, give alternatives and options to your stakeholders. Educate project stakeholders about software development, software testing so they understand why it takes so long to come up with a good product. Give visibility on risks.
- Make sure you have a clear definition of ‘done’ and the definition communicated to all stakeholders. No, a software is not done when you reach code complete. Far from it !
- Pay off your debt regularly and make sure the effort is part of the plan.
- Share the knowledge across your software organization. Code review is a good way to make sure you don’t compartment your knowledge.
- Use continuous integration with code analysis plug-in which give quick feedback (we use FindBugs, PDM, CheckStyle)
- Make sure you have enough testing done around your code. Write specific test cases for customer related issues. Start small and build the framework around the most critical piece of code. Focus on customer usage.
- Make sure management understand the iron triangle. The iron triangle refers to the concept that of the three critical factors – scope, cost, and time – at least one must vary otherwise the quality of the work suffers.