Like a heavy backback that eventually becomes to tough to drag aong, technical debt reminds us that develpoment and improvement of a software product becomes slower and more painful the heavier our debt is.
The concept of technical debt was coined by Ward Cunningham, the founder of the first wiki. He drew a comparison to financial debt – the bigger financial debt you’re in, the tougher it becomes to handle in the long run. However, technical debt can be useful and increase the speed of development for a short period. The problem first comes when you don’t manage your debt and in the end, it might end up impossible to sustain.
Types of technical debt
There are four main types of technical debt:
- Programming debt
- Design debt
- Testing debt
- Knowledge debt
Programming debt
Programming debt is simply about low code quality. This can be intentional (for example taking a shortcut to be able to deliver faster) or unintentional (such as architectural mistakes early on, high developer load or personal mistakes). Another example could be that the same code is present in multiple places, making it difficult to maintain.
One good way to get to the bottom of the issue is by using refactoring (from the agile world). Refactoring is about going back to your code and seeing if you can simplify it or make it more manageable. Microsofts Visual Studio has good support for helping developers with refactoring.
Another efficient way to avoid programming debt is by pair programming, where two developers together write the code. This way of developing has been shown a reduced number of code defects as well as the risk of invididual misinterpretation or misunderstanding of the requirements.
Design debt
Design debt can be many things, for example having a non-flexible architecture which makes it hard to customize as needs change. This in turn creates problem when adding functionality. Another example is having a faulty design on your layers or that the cluster of classes and modules become unsustainable in the long run. In Microsofts Visual Studio, you can find a lot of different tools for managing both design and architecture, to avoid nasty surprises during and after development.
Testing debt
Testing debt is easy to accumulate and the cause is often not enough testing, not extensive enough testing or not the right kind of testing. Sometimes it can be hard to know whether you have a faulty test or faulty code.
Many systems, including Microsoft TFS and VSTS, have support for unit testing. These unit tests can then be automated to run at for example a code check-in or before application building. When using unit tests, you can also get reports for test status after the build is complete – for example in order to see how much of the code has been covered by the automated tests (a concept called code coverage).
Knowledge debt
This type of debt can happen because the code is not commented well enough, making it difficult to maintain. It can also happen because of the lack of a good feedback and learning process. Lacking such a process means that knowledge exchange doesn’t occur throughout the project or organization. This can in turn result in other developers making the same mistakes as others already have.
The lack of good documentation can also give new developers or management problems understanding the code. In true agile spirit it’s not necessary to document yourself to death. However, you need enough documentation to keep the product maintainable and understandable.
Conclusion
Technical debt is in itself often no big problem. You need good overview and not let the debt grow without managing it as fast as possible, otherwise it will take a lot of money and resources to maintain your code in the long run.
Do you have a lot of technical debt? Let us know in the comments how you handle it!