Filed under: Technical debt, — Tags: Gaining weight — Thomas Sundberg — 2016-08-06
The traditional way to describe technical debt is to compare it to a bank loan. Something you do consciously. This is the way technical debt is described by Ward Cunningham[1] and Martin Fowler [2] .
Even if technical debt is usually described as a conscious decision, most technical debt seem to occur out of the blue. You realise after a while that you have it. If you are unlucky, you don’t even notice. The only indication you have is that seemingly simple things takes forever to implement. Your development becomes slower and slower.
Maaret Pyhäjärvi offers us an alternative metaphor and describes technical debt as gaining weight [3]. Most people that gain weight do not really know exactly what was the cause. Which hamburger added those extra grams? A lot of people are aware of that gaining weight is, at least partly, a lifestyle choice. But they can’t tell you what event lead to what weight gain.
The same applies to software development. Building technical debt is the result of your development style. Not automating your testing makes testing slow and painful. You tend to be afraid to do changes when you can’t see their consequences fast enough. This stop you from doing necessary refactorings as you don’t want to break things. Not refactoring enough builds up your technical debt.
The solution is to add tests before you do any changes. Tests are your safety net and will reduce the odds of getting into trouble with a broken system.
If you can, you should test drive your development. That is, add the test you want before you do the actual implementation. You may think that your system is special and can’t be test driven, but think again. Your system isn’t special and it can be test driven. You may not know how, but it is possible. In my career as developer, a couple of decades by now, I have never worked on a system that is impossible to test. Some systems have been hard to test, but never impossible. The problem has always been in the head of either the management or the developers. Since they don’t know how to do it, they decide that it is impossible.
If you don’t know how to test drive your development, this is the time when you need the help of a consultant that knows how to test drive the development of an application.
Most technical debt is not added consciously, it is added by accident. Or lack of knowledge and competence.
The solution is to refactor the application in small, safe steps in a direction where the technical debt decreases and finally disappears. Or live with the fact that changes takes forever and breaks the system.
Bring in expertise if you don’t know how to reduce your technical debt in small steps.
RSS