Technical debt sounds scary. From what we know from financial debt, all debt has some inherent risk that it starts consuming all the income/revenue one has. One becomes insolvent and that is not at all what one wants to be. That same thing may happen with technical debt too. If all development efforts are used up by maintenance tasks and no actual progress can be made, a project or organization reaches technical insolvency.
On the other hand taking on financial debt is fairly common for enterprises, because of an effect called leverage. Enterprises are often able to make a higher return on an investment than the investment loan charges in interest. Also limited companies may not be in as big trouble when becoming insolvent as a natural person.
Fairly similar principles apply to technical debt as well. Enterprises take technical debt to reach market readiness earlier, accelerate research progress or to get a prototype for evaluation earlier. The main difference is that it is hard to quantify technical debt and to anticipate the effects it will have in the future.
What is it exactly?
Let’s be lazy and just take the Wikipedia definition.
[Technical debt] is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
Wikipedia – Technical Debt
The key issue here is implied cost. It is typically not visible or quantified. Some techniques try to change that. There is A LOT of visualization approaches. The most hands-on I heard about yet (even though not proactive) is to put a post-it with the time lost on a (team-wide) board every time something hinders your development progress. If there is already a post-it, append it to it. The main advantage of this is that the costs documented are very real. They are real time lost and not some estimate made by someone. It is also a great vent for the frustration that often comes with working on bad software. Unfortunately I can’t find that article anymore.
Typically, the decision about technical debt is made by developers individually or in coordination with managers. In both cases the technical assessment of developers is required. Even though it is important to be open about technical debt if the debt is beneficial to the organization there certainly are cases, where it is not worth it. Developers should communicate such cases clearly to the management. The decision is ultimately up to a case-on-case evaluation but the next section will discuss common cases where the decision should (almost always) be to reject taking on technical debt.
Which is not worth taking?
There are some types of technical debt that I don’t consider worth taking. This is based on personal experience and might not apply to your specific situation. So take it with a grain of salt.
Skipping Tests
Skipping on tests is always a bad idea. Unrecognized regressions will become visible fast so there isn’t even a short-term benefit.
Using a different approach that is not later restructurable
If a completely different solution is chosen, where it is clear that it does not fulfill the requirements, a complete re-implementation will become due sooner or later. That change must then be made in an already integrated system, adding additional complexity regarding interface stability. For example using a bunch of VMs (in the production environment) if it is clear that containers will be required for scalability later.
Discussing the design with colleagues
No matter how stressed you and your colleagues seem to be, discussing advantages, disadvantages and possible improvements to the topics you are currently working on is almost always worth the time. In fact, it often leads to a simpler design that can be implemented faster.
Stashing significant amount of work-in-progress
Interrupting progress on tasks in-progress may be appropriate for single developers which are strictly required for another task. Doing it for a whole team is probably not. It is hard to later pick up work again that was interrupted at some point. A potential option is trying to find a big set of changes that can be integrated and documenting what is still open.
Code Review
Code reviews should not be skipped. The reviewer might be a bit more gracious in letting some non-technical issues like bad variable names or unlikely edge cases through, but at least one additional person should have a look at the code before integrating it. Issues will only come up later in the testing cycle, which will cause even more effort.
Skip on in-code documentation like docstrings, comments or similar
Just do it! Everyone and you yourself will be thankful later.
