Technical debt: How to kill the weeds in your codebase garden!
Imagine this: you are a developer and your project manager asks you to add some button. He (or she) will ask you: “how much time will it take?”
You know you have two possible answers: one assuming you will do it the right way, and one assuming you will do it the quick ’n dirty way.
Technical debt is what builds up in your codebase when you do stuff the quick ‘n dirty way. If you have none of it right now the right way will be also the quick and easy way!
Actually, as you gain more experience, you start realizing it's not even quick because you or someone else will have to “fix” it sooner or later wasting even more time than you “saved”.
Technical debt (I will call it TD from now on) is the weed of your codebase garden. If you don’t cut it as quick and often as needed they will silently grow more and more until that day when something goes horribly wrong OR you need a full week to plant a tiny flower.
Someday, you will have to burn your entire garden and it will be very risky and pricy!
The problem I had in my good ol' “junior developer” years is not recognizing when was it ok to leave some weed in your garden because you don’t have the time now and when to insist on taking this time.
We live in the real world and I want to share with you a realistic solution to this problem. Simply saying “you must prevent any TD all the time at any cost” doesn't make this a very useful article, does it?
Let’s start with how I used to deal with TD years ago (hint: I sucked) and how I deal with it now (hint: I suck less).
How *NOT* to deal with TD
Let’s go back around 10 years ago. I was an excited young developer* and all I cared about is writing perfect code.
*I’m still excited, just a lil-bit older and smarter now 🤓
I didn’t care much about how much time I spent nor about deadlines, not to mention any complaints about my awesome code.
As a result of this attitude, when I got any task it was likely the case that I wandered off of the task at hand and went after a more interesting clean-up adventure that would usually suck me into a very deep rabbit hole.
In my defense, I did clean up a lot for very good and reasonable reasons.
The problem was that I identified (maybe even assumed?) the presence of TD and I took actions regarding it in an under-the-radar kind of way.
I didn’t inform (or better, discuss with) my colleagues nor business people about those expected time delays.
I didn’t explain WHY we needed them and how the extra time needed for them will be justified. To them, I was simply a slow and defensive junior developer, and to me, they were ungrateful to my hard effort to leave any code I touch better than it was.
To be honest, something felt fundamentally wrong!
I was going the extra mile and I work/care even more than most of my colleagues, so why isn’t anyone (including myself) happy?
Let’s see what's wrong with this approach:
- I needed more time than planned for most features and bug fixes.
- My PRs were bigger than needed/expected and had more noise like renames of variables and even files and folders moving around.
- Due to the noisy and large PRs, it was harder to review and triggered more comments and questions than needed. I had to defend myself and I felt bad when I had to revert my piece-of-art work.
- I was usually in self-defense mode when I had to explain why my ticket was still in progress especially to business people who never saw my amazing code, to begin with.
Luckily, I finally knew what was wrong and I found a nice way to get the best of both worlds.
OK then, how should we deal with TD?
Before even discussing TD your company needs to have some “prerequisites” or minimum requirements. If your company doesn’t follow those basic software development approaches then you have much bigger issues than TD!
Your company should:
- Use Git or similar code versioning systems.
- Follow some agile approach like Scrum or kanban.
- Use Jira or a similar tool to break work into smaller chunks.
- Care enough about quality and efficiency to consider doing something about your team’s constant complaints about TD slowing them down 😏
All good? Then here is what I suggest you do to tackle TD:
- Discuss your intention to handle this issue. Make sure to include your team then slowly go up as far as needed to keep everyone in the loop.
Use your magic to get more people on your side.
Project owners for example LOVE when things get done fast, right?
Explain to them how doing those hard-to-explain non-feature things will result in fewer bugs, more features, and happier developers! - Talk to your team and team-lead and add a new weekly or bi-weekly meeting to discuss pain points and TD. Collect ideas like: “our tests are slow”, “we need to reach 80% coverage”, “running the dev server is weird and complex” or “we need to switch to the coolest JS framework, AGAIN!”.
- Create a story or a ticket with a title like “Technical dept sucks 💩” or something less cool, as you prefer 🤷♂️
Add all the collected ideas as sub-tasks. It’s critical to give a good title and description that focuses on the why (for business people surprised with this ticket in their backlog) and how (for the developer who is going to implement it).
Bonus points if you can even estimate them! - When you work on other tickets during the sprint and come across this very-tempting, mind-blowing awesome refactoring idea: add it to the TD ticket as a sub-task and move on with your life.
I repeat: DO. NOT. DO. IT. IN. YOUR. OPEN. PR. - Finish your work and when the next planning meeting comes vote with your team on the most important, urgent, or valuable TD tickets and ask your PM to include a few of them in this sprint.
If they are well explained, well estimated, and hopefully quick to implement your PM will hopefully accept your request and include them. - Continue the loop of defining, discussing, and destroying TD.
Your team will enjoy this slow but steady feeling of faster, easier, and friction-less developing experience. It’s not a linear line, with each fix you should become faster and more productive while preventing more bugs that would have had wasted more time and so on. - Profit!
Of course, things don’t always go as planned.
A deadline will come along and your request will be denied or some very ugly TD issue might require an immediate fix. However, overall, this approach is definitely a hundred times better than the old way.
It’s transparent, guilt-free, expected, planned, and most importantly: appreciated!
Also, now we have this always-ready backlog that we can work on when we don’t have enough new features. You PM will appreciate not having you nagging him/her for things to do when nothing is ready yet 😉
I hope this approach will be as life (or at least: work-life) changing as it was to me.
Let me know in the comments section what is your current approach and your feeling about mine :)
