The right way to deal with Tech Debt
If you are having problems to find the priority to deal with technical debt, this reading is for you
👉🏼 All our software has technical debt. That’s a fact.
☝🏼 What is also a fact is that finding the time to deal with it in our sprints is not easy.
Or maybe yes.
In today’s issue, I will explain how the teams I deal with Technical Debt, to have it under control, in the teams I work. In detail:
The problem to solve.
Apply the Girl Scout Rule.
How to convince Product Management.
By the way, at the end of the email, you will find some related readings that will find interesting on today’s topic.
🧐 The Problem To Solve
☝🏼 I will now read your mind to find out what’s your problem with the technical debt.
You have many software applications.
All of them have more or less technical debt.
Your Product Manager wants features and more features for the customers, who at the end of the day are the ones paying everyone’s salary.
And it’s not possible to prioritize the reduction of that technical debt.
Does it sound familiar? Yes, you are right, I didn’t read your mind; it’s just all of us have been there.
I proposed a way to deal with technical debt, in this past email here 👇🏻
What I proposed there is, basically, that you allocate dedicated effort, like 1 sprint, from time to time, to focus on reducing the technical debt of some codebase.
☝🏼 Honestly, that solution works when you have a concrete software applications, kind of old, not been touched in a long time, and that now requires tackling its technical debt. However, this represents a small percentage of the cases we have to deal with technical debt.
In the majority of cases, we have to deal with technical debt that happens, in a recurrent manner, in the software applications that are active and modified frequently because of business requirements.
👉🏼 Some of us found a solution to that problem.
🎯 The Girl Scout Rule
I know, you will find it on the Internet as the Boy Scout Rule, but I prefer to call it the Girl Scout Rule.
I will not write a lot of paragraphs about this, let’s go straight.
☝🏼 The idea is pretty simple, and comes from the Boys/Girls Scout society:
Leave Things BETTER than you found them.
Robert C. Martin (a.k.a Uncle Bob) adapted it to something closer to software engineers:
Always leave the code you are editing a little better than you found it.
👉🏼 This means that you will tackle technical debt when you implement new features in your software applications.
Whether you use sprints or not, you will invest effort to reduce the technical debt of the code that you have to modify to implement that brand-new feature that your beloved Product Manager asked for.
So, instead of blocking sprints to code on technical debt, you spread that effort across all the sprints. See the picture below.
What you have to do is include the time/effort to reduce the technical debt in the services that you will work on. Little by little, there is no need to reduce all in one shot.
☝🏼 It’s not an easy task. In the beginning, you will find yourself taking more time than you planned because of some unexpected surprises in the code. Take the profit I’m telling you now in advance and book a bit more effort to reduce that impact as much as possible.
👉🏼 By addressing issues as soon as they arise, you can avoid larger problems later on and save countless hours of confusion and overtime.
Remember: You are the owner of the technical work; Part of your work is keeping the technical debt on track. You are accountable for that. Share this with your Engineering Manager, and plan the work, she/he will support your plan.
How does it sound to you? Feasible?
All right, let’s wrap up for today.
✨ Takeaways
Dealing with technical debt has been historically problematic. The pressure to deliver new features is there and it seems there is no time for anything else.
But there is another way.
[…] it seems there is no time for anything else […]; That’s a myth you have to drop from your mind.
It’s possible to reduce your technical debt and keep delivering features, no matter what your Product Manager tells you.
You, as Software Engineer, are the owner of the technical debt. Reduce it is your responsibility.
Include work on technical debt during your work on new features.
Embracing continuous improvement means that, rather than waiting for a major refactoring, you and your team can implement small, incremental enhancements regularly.
Finally, I want to thank one of my most active readers,
, for answering my email and proposing this topic that I wrote about today. Here you can find his newsletter 👇🏻
If you want to propose a topic for me write, answer this email, or drop me a new one👇🏻
We are ✨1059 Optimist Engineers✨!! 🚀
Thanks for your support of my work here, really appreciate it!
If you enjoyed this article, then click the 💜. It helps!
If you know someone else will benefit from this, ♻️ share this post.
Thanks for sharing. That's an interesting approach.
Do you have any example of applying the boy scout rule?
Our team is improving test coverage along with the development, but that's the only thing I can think of. I'm wondering if you have any other example of tackling technical debt when doing development task.
I've always tried to apply the boy scout rule. It's a great habit and no need to ask for extra time.
Thank you for the shout-out at the end!