Stephan Schmidt

Stuck in Technical Debt? Do this

How to get out of that miser and live a happy life

Part of my CTO Coaching

You’re stuck with technical debt. Development has slowed down. Developers are unhappy with the code they have to work with. Product Management is unhappy because small changes take ages. The CEO is unhappy because nothing is accomplished. I’m not talking about a small amount of technical debt, I talk about a crisis.

As a coder and engineering manager, I often came into contact with technical debt in my career. If you don’t actively work against it, it will grow and grow into every corner of your code. I have seen complicated code bases that no one understood, I have seen code bases with ruins of framework transitions, I have seen internal web frameworks that were no longer supported or developed—and which made it a pain for new developers to get into. I once joined a company as an engineering manager with 150 open bugs—and five developers. I have worked as a fractional CTO in companies with an incident once per month due to bad code. You could not fix a bug, it created several new ones.

How do you get out of the technical debt crisis?

Before you take action, there are some considerations and preparations.

First, decide if the technical debt is strategic or accidental. If it is strategic, it might be a good thing. If it is accid ental, get rid of it. I wrote about this in “Accidental vs. Strategic Technical Debt”.

Second, find out the reasons and drivers for your technical debt. You can’t fix the problem if you are not aware of the drivers that drive the problem. I wrote about this in “Reasons for Technical Debt—What drives technical debt?”.

Third, you may live in a culture of technical debt. With that culture in place, you can try to fix technical debt, but it feels like fighting a Hydra, slaying one head and another pops up. I wrote about cultures in more detail in “Engineering Cultures of Technical Debt”.

Now that you’ve done your homework, how do you get out of technical debt?

If you have a leaky bucket, fix the bucket before you pour in water. For technical debt this means:

Stop the line! Call out an emergency. You’re now in crisis mode.
Create a vision how golden the future is after the team got rid of technical debt, what it means for developers, how it enabled the company to succeed. Lead developers to that vision!
No more shortcuts. Make it clear to everyone that this is an engineering organisation, and you don’t do shortcuts. Features are developed the way they are intended to be developed (“No SQL in controllers”).
Create a culture of craftsmanship, write it down and roll it out.
To fix technical debt, reduce new feature development to 20% until the problem is fixed.
Send out a questionnaire to all developers asking them to rate all systems/packages/parts of your application to low/high technical debt.
Every developer needs to read the Refactoring book (“Too Many Developers Get Refactoring Wrong”)-introduce a policy of constant refactoring (“Boyscout rule”)
Restructure QA: Developers write all tests and are responsible that their code works. QA does code reviews of all tests.

Then fix technical debt:

Make individuals (leads and ICs) responsible for technical debt in parts of the application (Directly Responsible Individuals - DRI)
Upgrade all your dependencies to the newest version.
Rewrite if necessary, but be aware of how rewrites fail
When new as an engineering manager, best to fix technical debt problems in the first six months. Then you’re still part of the solution, after six months you’re considered part of the problem.
Add all the linting and static checking you can get. For me in Go this is staticcheck, golangci-lint, nilaway, arch-go, gosec, govulncheck and nancy.
Make tests a requirement, set the goal of branch test coverage to 80% - write tests or start by let an AI write tests for you.
All code needs to go through a code review before it reaches (No, all code!). You write or delegate a code review guide and checklist (short). Code reviews are NOT about naming conventions (see static-checking above).
Fix technical debt problems one by one. Keep a track record on how great you are doing to keep people motivated. Keep the vision in everybody’s mind. Talk about the golden future.

Getting rid of technical debt is a hard thing. The best time is around PMF, where the product hits the nail and marketing can drive growth for some time. To solve the problem, stay focused and on track. Don’t get sidetracked on your quest to destroy technical debt. Then you’ll suceeed.

Good luck.