Stop Walking the Path From Technical Debt to Bad Code
A helpful list of steps to grade your technical debt so you can take action before it becomes an unsolvable puzzle.
Join the DZone community and get the full member experience.Join For Free
Ward Cunningham, when coining the term technical debt, warned of incremental debt that allows code to run effectively but imperfectly. What this means is that if the debt is payed back promptly, everything should be fine. But if you let the debt sit and accrue interest, the code riddled with debt can compound and collapse causing huge issues for the team that owns it. Kimber Lockhart, CTO of One Medical Group, goes into detail on the practices that can help start ups control the technical debt. Lockhart presents a pragmatic way in which to use shortcuts in environments where speed is deemed tantamount to quality.
So how do you handle technical debt before it becomes bad code?
First, we should discuss how debt, in all of its forms not just technical debt, has strong negative associations. It is often seen as a weakness, when in fact it can be a useful tool. In actuality, high performing teams often take on technical debt. The main difference between these teams and those that struggle, is that high performing teams make controlled decisions to take on debt. For a growing business well-thought-out shortcuts (tech debt) can be a strong enabler for growth. However, when too many of these shortcuts are taken and technical debt is allowed to sit unattended bad code arises.
The key to using technical debt effectively is recognizing that it is not carte blanche to take as many shortcuts as you want without any forethought. For example, if you are trying to find your product’s adequate product/market fit you may want to build as quickly as possible in order to see whether what you are building is right for your audience. In this case taking on some debt may be a good idea. Technical debt is not inherently bad, it’s how you manage it once it is incurred (and how it was incurred) that makes it either a good or bad thing.
There are various ways in which to keep technical debt from turning into bad code.
- Mixing ‘green’ and veteran developers so to ensure that there are various perspectives on a team when managing technical debt
- Having code review start before any code is actually written allows the team to come up with the most pragmatic action for a specific item before having to write code (or expend effort rewriting it)
- Codified standards are a must (teams can use standards developed by OMG or CISQ)
It is important to know that shortcuts don’t always save time. The decision to take an ineffective shortcut is not due to the task at hand but more to do with the surrounding circumstances. In organizations where deadlines are too tight, developer teams can begin to take shortcuts at every turn and can end up creating more work in the long run. That is why the steps outlined above are necessary in order to keep technical debt from being something done out of habit rather than a tool used in a conscious and controlled manner.
But what do you do if you have already let your technical debt compound into bad code?
After too many shortcuts have been taken and technical debt is rampant what you are left with is bad code. What you have to do is prioritize, label, and navigate this bade code according to a rating system (so that you know what code is the most dangerous and which can be left to handle another day).
This rating system should be created according to the following factors:
- Security: does this bad code pose security issues to your system?
- Prevalence: how widespread is this bad code throughout your system?
- Frequency: how often does this bad code come into contact with developers or users?
After rating code based on these three factors a rating of the code begins to emerge. Your next step should be to encapsulate and label the code:
“If there’s part of your code that you know is bad and don’t want people to repeat it, label it. With that act, you’re explicitly indicating which code should no longer be followed, even if it’s currently necessary for functionality,”
Labeling and encapsulating the code keeps it from further spreading throughout the codebase. Which is big step in keeping bad code in check.
Once you have instilled these practices in your product you are on the right path to dealing with technical debt. But it doesn’t resolve the issue entirely, you have to go in and refactor your code so that these pieces of bad code no longer exist and but strain on your system.
To read the original post visit here.
Opinions expressed by DZone contributors are their own.