I recently went through Dave Farley's guide on Managing Technical Debt. It’s a mandatory read, mostly because it treats debt strictly as a business risk, not just a developer complaint.
I have spent the last two decades fixing systems that "moved fast and broke things."
Spoiler alert: they usually stayed broken.
Here is my take on Farley’s concepts, filtered through years of battling legacy Java monoliths and migrating them to AWS.
1. The "Bit Rot" Reality Check
Farley talks about "Bit Rot"—the idea that software degrades over time. We know code doesn't physically rust.
Farley defines Bit Rot as a symptom of neglect. It happens when teams fail to refactor and "tidy up" as they go. It’s the kitchen analogy: if you cook a five-course meal but never wash a pan or wipe the counter, eventually you can’t cook anymore. You are paralyzed by the mess.
I see this constantly in Java modernization's and Cloud migrations. A team lifts-and-shifts a Java application to AWS. They don't refactor. They don't modularize. Is updating just jdk a modernization?
The result? You have a 15-year-old monolith running on expensive EC2 instances. Every time you try to patch a security vulnerability, something breaks in a completely unrelated module.
My rule: If you aren't leaving the code better than you found it, it is already rotting.
2. Configuration Debt: The New Spaghetti
This is the part of the guide that hit home the most.
In the Java world, we spent years learning how to avoid spaghetti code. But now, I see "Spaghetti Infrastructure."
- Security Groups defined manually by clicking in the UI.
- Lambda triggers set up in the console, undocumented.
- Terraform states that are out of sync with reality.
This is Configuration Debt. It is arguably worse than code debt because it can bring down your entire environment, not just one feature.
If I catch a developer changing infrastructure settings manually in the AWS Console, we have a problem. Not because I'm a purist, but because that manual change is a ticking time bomb for the next person who runs the deployment pipeline.
3. The GenAI Trap: High-Speed Legacy
This wasn't in Farley's original text, but it belongs there now.
Tools like Copilot or ChatGPT are incredible. I use them daily. But for a disciplined team, they are power tools. For an undisciplined team, they are High-Speed Debt Generators.
I am seeing Pull Requests filled with AI-generated boilerplate that the author clearly didn't read closely.
- It works? Maybe.
- Is it efficient? Rarely.
- Does it handle edge cases? Never.
Remember: "Bit Rot" comes from neglect. If you generate AI code without ruthlessly refactoring and testing it, you are neglecting your codebase at 10x speed. You aren't "coding faster"; you are just automating the creation of Legacy Code.
My rule for AI code: Treat it like code written by a drunk intern. Review it twice as hard.
4. Test Debt: The High-Interest Loan
"We will write tests later."
No, you won't. I have never seen a team go back and "backfill" unit tests once the feature is in production.
Test Debt is dangerous because it kills velocity. Without a reliable test suite (and I mean fast, automated tests, not manual QA), you become afraid to change the code.
When you are afraid to change the code, the Bit Rot accelerates because you stop refactoring. It is a vicious cycle.
Summary
Technical Debt is inevitable, but it must be a conscious choice (like a mortgage), not the result of incompetence (like gambling).
- Refactor constantly.
- Codify everything (especially infra).
- Don't let AI write code you don't understand.
We are paid to solve problems, not to create new ones for the future.
Top comments (0)