It’s a rite of passage for software engineers to inherit a legacy project and complain about it. We’ve all been there. We’ve talked about how the previous owners could’ve built less tightly coupled components, written cleaner code and tested more.
But most code bases start out very simple and clean, with the best intentions. Over time, though, tech debt slowly accumulates until it becomes an unmanageable burden on team members.
The hard part isn’t starting a software project with high standards and the right intentions, it is maintaining those high standards when you’re in the middle of fulfilling urgent business requirements. It is maintaining consistency when you’re constantly losing old team members and onboarding new ones. If you can’t do this, your project will ultimately end up as one of those painful legacy projects no one wants to maintain.
In this article, I discuss some strategies to keep tech debt under control in an ongoing project. This article is the final part of a three-part series about tech debt:
Part 3: How to keep on top of tech debt in an ongoing project (this article)
There are some tried and tested processes that are a must-have for managing tech debt effectively. Ensure that your team follows at least the following basic processes:
Code reviews
Automated testing
Continuous integration/delivery
For a more comprehensive understanding of good engineering practices, read the book Software Engineering at Google. (I’m sure there are many others, this just happens to be my favorite one on the topic)
The most effective way to enforce a code quality standard is through automated checks. We could have the best intentions, but we’re all human and we’re prone to mistakes and forgetfulness. It is best to rely on tools to do the gatekeeping for us. Some examples for such tools are:
Test coverage - e.g. Jacoco
Code style and linting - e.g. Checkstyle
Code quality static analysis - e.g Findbugs, Sonarqube
As James Clear notes in his bestseller Atomic Habits, the most effective way to create habits that stick, is to make them easy to execute. To help your team build a habit of writing good quality code with high test coverage, reduce the friction by making it easy to run the tools and controls we listed in the above section.
Use an IDE that clearly shows code coverage as you’re running tests locally. Make the controls a part of your builds that run as part of your pre-commit hooks, then on the creation of a pull request, and then before and after merging the code to your main branch.
Imagine you want to get your kitchen renovated, and you ask a builder how long it will take them. If the builder does a shoddy job of it, they can finish it within 2 weeks, but there’s no guarantee that your kitchen won’t fall apart soon after. If you want better quality guarantees, the builder will need 4 weeks to do it properly. Which estimate would you want your builder to give you?
As a software engineer, you know your trade best. When providing an estimate for a task or a project, factor in the time needed for ensuring quality - testing, clean code etc. The quality controls are part of your deliverable, not a bonus.
How many times have we seen comments in code that say “TODO: Refactor this” or “TODO: Remove duplication”?
When you touch a piece of code as part of delivering a business requirement, it is usually the best time to clean up any problems surrounding it. If you introduce any tech debt with a plan to come back and clean it up later, it’s most likely never going to happen.
Urgent business requirements and other extraneous situations might sometimes trump this rule, but ensure that this is the exception rather than the norm. If you have something to clean up in your code, DO IT NOW.
Managing tech debt is not the sole responsibility of your manager or tech lead. Build a culture where every member of the team is empowered to call out code quality issues via code reviews or other means.
You might be tempted to lower your quality standards when you’re working against tight deadlines, but your teammates should be holding you accountable, and vice versa.
Ensure you’re regularly taking out the time to reflect on your code quality standards and processes. Discuss what is and isn’t working for you, and strive to continuously make improvements in this space. Keeping on top of tech debt takes constant effort, but it is worth it for both the business and the engineering team morale.
I’ve been listening to Storyworthy by Matthew Dicks on Audible. Matthew writes about turning everyday moments into compelling narratives. It resonates with me because I like to share stories from my day to day experiences as a software engineer on my LinkedIn.
As part of my efforts to understand Python better, I found and watched this video on Python coroutines. What a lightweight concurrent programming technique!
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.