Technical debt is a common metaphor in software development, taking shortcuts will allow us to ship code faster, but in the long term makes the code harder to change and extend. There are many many articles on cold rational reasons why you should always go for the clean slow proper programming and avoid all those sneaky ways to accumulate technical debt.
We won’t go on showing fancy graphs of how it accumulates and how it impossible to add new features. We won’t allude to your better side, that you should know better. Also probably you won’t be going away here nodding and promising yourself that you’ll wake up tomorrow and write clean respectable code. We will take a look at how those spaghetti shortcuts come in from a few different perspectives.
Now they might not all be applicable or relevant for your use-case but in general, they might help explain how its current state came to be. Who? you might ask. The one project everyone at your company avoids, whose mere mention destroys even the happiest of office moods. I personally like to refer to it as Hastur! Him Who Is Not to be Named!
Back to reality, this is just the first of the series of posts that look into different aspects of the Technical dept. Check out the article that looks at the topic from a business management standpoint, which might make it easier for you to get your management on board towards reducing technical debt.
Technical debt as a habit of procrastination
Do you know what the previous section and most technological debt articles remind me of? Articles about weight loss and procrastination. All three share the same mental process: “Prioritizing short-term satisfaction that hurts your long-term goals”. Also, the bad ones talk about rational reasons. Like I need you to tell me that never exercising is bad! And good ones focus on ways we sabotage ourselves every day.
Eating a jar of Nutella won’t make you overweight. Finishing work early on a Friday so that you can finish a new game in one weekend won’t make you a bad employee. Rushing the last two days before a deadline won’t make your code an unmaintainable mess. Trust me I did all three repeatedly during the great stay-at-home of 2020!
The habit of always choosing the shortcut leads to technical debt
Now, do any of those daily or even weekly, and you are in for a bad time. The problem is not in the single act, but in the habit that might develop from it. Try reflecting on your last workweek and finding patterns. Cases where you felt obliged to rush something or avoid documenting something, or proofreading comments. Such patterns might give you some insights into what triggers you to choose the easy way out. Knowing them is the first step in avoiding or preparing for such situations in the future. If you’d like to really dig deep into optimizing personal and workspace habits, I wholeheartedly suggest the Atomic Habits book. It’s a very good starting point for analyzing all the little things that you do without thinking about them every day.
Now sadly, as most blog posts, this won’t be a complete guide on how to solve procrastination or shortcuts in code. But we will leave this topic with a video on procrastination. Watch it, and then try watching it again and replacing the word “procrastination” with “quick and dirty code.”
How organizing work can increase Technical debt
This might be slightly out of your hands, but it’s still very important for understanding technical debt. Let’s say that your company evaluates and rewards based on performance during technical demos. They want to see the thing perform, and if it works as it’s supposed to: Great Job!
Now if you control the demo, what stops you from just having mockup HTML pages or even PowerPoint slides that you can “click-through” as you would the actual app. If your reputation or your salary depends on taking such shortcuts, well you will start taking such shortcuts. Or worse a coworker will, and you will be forced to choose between your principles or finding another job. And this is a classic case of reward systems becoming contra-productive.
All you can do is talk to your coworkers and management about adjusting expectations and agreeing on how to avoid such bad edge cases. As long as you shift the focus from individuals to systems, bad incentives can be handled without causing harm to the people involved. But stay tuned for our upcoming article on the business side of technical dept.
Technical debt accruing from inconsistent code style
This is probably the simplest technical dept to deal with. No matter what language and what style you prefer, each one is much better than using multiple at the same time. Mixing different indentation and layout stiles makes the code ugly and hard to read. Additionally, using different cases and variable naming schemes might make it hard to find and reuse said variables.
Luckily the remedy for this is supper easy. You just have to do the following 2 google searchers:
- Coding standards for <<insert language and/or platform>>
- Automated code checks for <<insert language and/or platform/standard>>
After the first search agree on a single standard for each of your platforms/projects. Next first run the check by hand to figure out how much work it will take to move everything to the new standard and then decide how to best tackle the transition. In most cases, an IDE should be able to correct it all, or worse case someone will have to spend an hour or two workings on it.
But if it’s too much work to change it all; don’t give up, just pivot! Simply make it a goal that each new contribution should increase or maintain the % of code compliant with standards. That way your new code won’t make things worse, and whenever your old code gets changed developers will have an incentive to rename and reformat a thing or two.
As for the second point, add an automated code check to your CI/CD pipeline so that developers simply get this information without having anything to do to get it. If you put the extra effort to report the number or %change in your merge/pull requests you will see that suddenly your team started talking about code quality on their own. It may sound daunting, but all you need is a simple docker container that starts with your code and spits out the result.