We often hear the phrase Technical Debt and usually the first thing we feel that it is a bad thing, something has been done in a wrong way. What is really a technical debt? Is it really bad?
I did some research before writing this article just to have an overview about what people are thinking of Technical Debt. Most of the time when this phrase pops up, we are thinking about TODO comments, messy code, hacky solutions, bad code which will never change. Technical Debt is not black and white but a colorful thing if properly used.
In a software development project you always have 2 perspectives at least. The business and the development team. Of course there are more but let’s focus on these two.
Business wants more business value as fast as possible. The team wants to make the code right to achieve scalability, maintainability, etc. The business states the requirement and the team has to fulfil it in an acceptable time-frame. As you are probably familiar with the situation, this means that you have a limited time to work on a specific feature. There are cases when the business says that you have let’s say 2 days for this feature but the developers have checked it and it turns out that this feature requires more than 2 days to be implemented correctly in a way where it’s easy to extend and maintain it.
Now you are in a situation where you have to decide, will you write messy code to deliver the feature in time or will you write code which is easier to maintain and will pay off on the long ? Of course this is the choice of the business. But a question rises here; how could you describe the problem to pure business people? They don’t know how a software is build, what is maintainability, what is scalability, they just don’t know how to code and what costs it will have when doing messy implementation.
Originally the metaphore Technical Debt was created by Ward Cunningham when he tried to explain this situation to business people. Financial people understand financial words. Ward used the word “debt” which was clearly understandable for those people as well as the developers and also added the “technical” word before it just to refer that this is a technical related debt.
Now the business might have a clue about what is happening and what will be the cost of putting more and more debts to the code in order to deliver fast.
Technical debt is not necessarily a bad thing. Imagine a situation when you have a pretty foggy requirement from the business – meaning they also don’t really know what they want, or what will fit. In this case it’s absolutely a bad idea to develop everything right, make the code clean and maintainable and so on. In this case what we want from the business is feedback. Feedback what are they first thoughts about this feature – which is not even complete.
Technical debt has advantages:
- We can get quick feedback from the business
- We can deliver stuff faster
- Makes us learning from our mistakes. If you chose an implementation to be able to deliver fast, you will see the problems with it or you will see that there is no problem with this at all, and you can continue in this direction
There is one single essential part of technical debt, it is refactoring. In a nutshell, refactoring means changing implementation without changing behavior. The question here is how can you ensure that the behavior is not changed after switching to a different implementation. Without tests, this is not possible. This implies that for technical debt, you need tests to cover behavior in order to make refactoring possible.
There is an additional thing here. Of course the code should be clean enough to be able to refactor it. All right, we all know that there are places in the code which are that big of a mess that I don’t even want to touch anymore but that’s a different thing (described later on). 🙂
As we saw, technical debt is not a bad thing if used properly. Most of the devs are not using it as it should’ve been used, that’s why everyone is scared from it. Technical debt is a good thing as long as it’s repaid.
If you think that you have some kind of technical debt, ask yourself the following questions:
- Is the code clean? By clean I mean that if it’s necessary, you could refactor it
- Is the code tested properly?
- Is there a plan for payback?
- Is the business informed?
If you answered those questions and the outcome has at least one no answer, then you don’t have technical debt but just a messy code which should not be there. The problem with messy code is that it needs more and more messy code to maintain and at the end you will have a messy codebase which noone wanna touch.
Of course sometimes we need to write messy code because of the pressure from the business, we need to meet deadline. There is one big solution for eliminating the messy implementations, boy scout rule.
Boy scout rule is based on “leave the codebase better than you found it” phrase. This should be an essential part of a developer’s life. Also, don’t ask permission to do it. If you see something which is not quite right and don’t need that much modification, just do it instead of waiting for somebody to allow doing it.
If you really care about your code quality, it’s necessary to monitor your state and check out the trends. One tool which I suggest using is SonarQube. It’s a great tool, the basic configuration is almost enough and you can write your own plugins, rules to it.
Hope you liked the article and share your thoughts in comments or via Twitter and make sure you follow me if you want to have some more fun.