Long time reader Phil asks when do you fix the tech debt you used to ship faster
How do you get business buy in for spending some time on the tech debt and the improvements that are hard to prioritise against the main objectives for the quarter that are linked to the overall business objective
You can hope for a miracle. One day you'll win the lottery and that magic Tomorrow when you have time to do all the things will come.
But you won't. The odds are never in your favor.
Heroic efforts don't work
You'll never have a feature freeze. Not even for a sprint. A good business never runs out of ideas.
If you do have time to sit and fiddle with tech improvements for days and weeks, run away. You deserve to work for better business and product people than that.
The Senior Minset email crash course
Get a free chapter from the Senior Engineer Mindset book and a sample audiobook chapter, followed by a Senior Mindset 101 email course.
You'll get insights to apply at your work right away.
Unless you're a small team focused on the tech inside a larger organisation. That's different. Lucky you!
What you may get, once in a while, is a sprint that goes miraculously. The stars align and you find yourself with an extra day at the end 😍
amazing the stuff you get to do when Team gets the main sprint done early
— Swizec Teller (@Swizec) August 16, 2021
"fix it later" becomes "yes, today" pic.twitter.com/WzHyjq8JGn
POUNCE my friend!
Fix your favorite pet peeve. Improve your annoyingest repetitive process. Something. This is a rare opportunity and I hope you're ready with plenty of ideas and little annoyances.
You pay off tech debt little by little
Tech debt is a lot like real debt. You pay it off little by little over time.
A constant mindset of gardening and tweaking. No heroic efforts.
The approach that has worked best for me across different companies is to roll this gardening into your main work. Got a feature? See if there's a related story on the engineering backlog.
Can you pay off tech debt without endangering the main story? Go for it!
Can you fix a method or component while adding a feature? Do it!
Can you rewrite a weird loop that makes no sense while trying to understand the code? Fix it!
Can you leave that file a little better than you found it? Take out that trash!
Little tweaks here and there. Fix a hairy condition chain, tie a branch to the tree, pull a bad leaf, pluck a weed, lovingly tend to your codebase like it's the best flower garden in the world.
Not all debt is created equal
Tech debt will overrun your garden, if you keep adding more faster than you can pluck the weeds.
That's a recipe for disaster ... later.
You have to be careful about which debt is worth taking on. In my Tech Debt is a Tool email I wrote about how we avoided writing code to ship a feature to fulfill a new legal requirement quickly.
Code you don't write is good debt.
When it's for a good reason, even better. You can always add a feature later when you understand the requirements better. Or there's a clear business need for that feature. Or there's more engineers available to work on it.
All code is tech debt.
Yes every line of code is a liability. Even the beautifulest perfectest code you can think of – it's already tech debt. You have to maintain that shit.
Your code either dies a prototype or lives long enough to become that shit code you don't wanna deal with.
— Swizec Teller (@Swizec) October 12, 2018
Requirements will change and your beautiful perfectly designed wonderful code – it's trash. No longer fit for purpose, full of outdated idioms, hard to understand for people who don't think like you.
That includes the You 3 months from now. Future You is a different person.
An example of bad tech debt
Examples of bad tech debt abound. Think of any code you've had to fix that was written by somebody else.
Looked pretty bad huh?
Dissing other's code is weaksauce. Here's when I personally fucked up on a former project:
There was a UI I had to build that iterated over a list of questions and rendered them. Certain questions had sub-questions.
I squinted and thought "This is a recursive problem but bet you can I do it linearly with a .map"
And I did. Ho boy did I write the cleverest code in my life. I was so smart that the heavens opened and peppered my project full of bugs. The more bugs I fixed, the more it looked like I was reinventing recursion from scratch.
With every bug my "keep track of things" data structure looked more like a stack. With every fix my gaggle of variables looked more like all the things compilers keep track of to make recursion work.
All because I wanted to be clever. 💩
An example of good tech debt
How careful should you be of memory leaks on a missile?
Memory leaks on missiles don't matter, so long as the missile explodes before too much leaks. A 1995 memo: https://t.co/RIRF1u75Qt pic.twitter.com/6O4wi74bOW
— Clive Thompson (@pomeranian99) May 1, 2017
I was once working with a customer producing on-board software for missiles. I pointed out that they had a number of memory leaks.
"Of course it leaks" the CTO said
He pointed out that they calculated how much memory would leak in the total possible flight time of the missile and doubled that number. They added this much additional hardware to "support" the leaks.
Since the missile will explode when it hits its target, the ultimate garbage collection is performed without programmer intervention.
Take on good debt and go gardening 🌷
Cheers,
~Swizec
PS: the afternoon after that big chunk of sprint ending/starting rituals is my favorite time to go gardening. Dazed from a day of meetings, no stories officially started. 👌
Continue reading about Reader question: "When do you fix tech debt?"
Semantically similar articles hand-picked by GPT-4
- Tech debt is a tool
- Better is good
- Don't neglect your upgrades
- Let small fires burn
- Why senior engineers get nothing done
Become a *true* Senior Engineer
Get promoted, earn a bigger salary, work for top companies
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
The Senior Minset email crash course
Get a free chapter from the Senior Engineer Mindset book and a sample audiobook chapter, followed by a Senior Mindset 101 email course.
You'll get insights to apply at your work right away.
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️