As executives and managers, we know that technical debt is the worst inhibitor to engineering productivity. “Short cuts make long delays,” a wise hobbit once said in Tolkien’s epic, and developers’ pragmatic concessions to meeting the deadlines we set make that debt grow.
So how can we create a debt-free engineering culture?
To start, recognize what’s causing the debt. The most likely cause? Features.
Every software release is an opportunity to delight and engage the customer with new features or a new look. And we get rewarded for it when our products gain buzz in the press and in the marketplace.
But the drive to ship new features often forces developers to choose technical solutions that are easy and quick over approaches that are more flexible but require more time. Ship it now, fix it later — and later never comes, even as new obstacles emerge from the code’s shortcomings.
Technical debt is never due to having too few engineers. You can hire all the engineers you want, but if you don’t have the discipline to live below your means, the debt will continue to grow.
After a major release, ask yourself “Did I pay down the debt? Or did I just refinance?”
Paying Debt Down
Like any debt, the technical kind has interest costs that compound with time. The longer you wait, the harder it gets to implement changes later on. Unaddressed bugs accelerate entropy in your software, limiting the return on your engineering investment.
There’s a spiritual debt as well that risks making your developer teams discouraged when they feel unable to send their best, most bulletproof work into the world.
A practical, simple, and fun way to pay down your technical debt is to launch an initiative for a “No-Features Release.” Here’s how it works:
- There are no new features. Not a single one. No exceptions.
- Prioritize debt payments as a team. Focus on solving the biggest pain points first
- The whole team works together to pay down technical debt.
- Celebrate loudly, to yourselves and to the public, a release with no features.
Is this possible? I’ve done it at Microsoft and Google, and Apple did something much like it for their release of iOS 12.
It might seem challenging to get everyone on board, but once you do your engineers will turn it into a rallying cry that boosts morale.
You’ll make your customers very happy too, as they’ll be pleased by a more reliable and forward-looking product.
What are some of the of things you might focus on?:
- Security – Analyze your entire attack surface to better understand your risks. Put a Red Team Infrastructure in place to identify vulnerabilities. Obscure your attack surface and close any gaps.
- Performance – Improve page load times, API response times, memory consumption, startup/shut down times, and load testing.
- Observability – Improve logging infrastructure, error messages/warnings, and tracing. levels
- Plain Old Bugs – Go for quantity! Get to the P3’s and P4’s and you know you’re doing it right.
- Test infrastructure – Implement new unit tests, automated headless installation, feature tests, test reliability, code coverage, chaos monkey, fault injection, and load/stress testing.
- Documentation – Review all documentation starting with oldest first, and update or delete your docs as needed.
- Dead Code – Keep your code lean, and delete anything that isn’t still doing work.
When You’re Done
When we complete a new release, we usually like to tell our customers about the new things it can do. But once you’ve completed a no-features release, what do you have to crow about?
A lot. Tell the world you did a no-feature release because you care about quality. Boast how customers gain a cleaner, better performing product that can continue to grow with them as the technology evolves.
Just as important, share the story of your engineering culture with the world. Provide clear metrics of real improvements, such as how many bugs were found and fixed. Explain how the new improved infrastructure makes the team stronger.
But just fixing some bugs doesn’t change your culture. Following a no-feature release, use what you learned to incorporate debt reduction with every release.
Your engineering teams will be grateful, your customers will benefit, and you won’t keep making those technical cost payments anymore that drag productivity down.
Those are the kinds of features you really need.
