The first proposal was two paragraphs about code quality, mentioning a module that had become hard to change safely and a request for two weeks to refactor it. It got a polite no, the kind that comes with "let's revisit next quarter" attached. The second was longer, with more technical detail about coupling and test coverage, and got the same answer. The third had a diagram. Still no.
Each version had been written the way engineers write for other engineers, describing the problem in terms of the code itself, not in terms of anything the room deciding on it actually had to weigh against. Management wasn't rejecting the need, they were rejecting proposals that gave them nothing to compare against the other things competing for the same two weeks of engineering time. "The code is hard to maintain" isn't a data point next to a feature request with a customer's name attached to it, it's a feeling, and feelings lose to deadlines every time in that comparison.
The fourth version dropped the word "refactor" entirely from the opening. It opened with a number: the module in question had been responsible for three production incidents in a single quarter, each with measurable time-to-resolution, and every new feature touching that module had been taking roughly 40% longer to ship than comparable work elsewhere, based on ticket history anyone could pull. The ask was reframed from "let us improve code quality" to "here's what continuing to build on this module is currently costing in incident time and delivery time, and here's the two-week investment that stops the bleeding." Same underlying work but completely different proposal.
It passed in the same meeting it was presented in, which was less about the argument being cleverer and more about it finally being denominated in the currency the room was actually pricing decisions in. Nobody in that meeting disagreed that clean code was good. They disagreed, reasonably, on whether "good code" as a goal on its own was worth displacing a committed roadmap item, and no version of the pitch that stayed in that register was ever going to win that comparison.
If a tech debt proposal keeps getting deferred, the proposal is usually not wrong about the problem, it's answering a question nobody in that meeting is asking. The question being asked is almost always some version of what does this cost us if we don't, and what does it cost us if we do, both in numbers a non-engineer can hold in their head. Translate the argument into that shape before assuming the answer is politics.
More like this?
I write short production war stories like this one, plus a deep-dive architecture series. Subscribe here if you want both in your inbox.
Recommended Resources for Java & Spring Boot Engineers
If you are preparing for Senior/Lead Java interviews or looking to solidify your Spring Boot & Architecture skills, check out these highly-rated resources from the Javarevisited publication (Use promo code friends20 for an exclusive 20% discount automatically applied at checkout):
- Grokking the Java Interview Prepare for core Java, concurrency, JVM internals, and design pattern questions. Get Full Book (Paid) | Download Free Sample Copy
- Grokking the Spring Boot Interview Master Spring Core, Auto-configuration, Spring Data JPA, Security, and Microservices. Get Full Book (Paid) | Download Free Sample Copy
- Grokking the SQL Interview Deep-dive into query optimization, indexing, joins, and complex SQL window functions. Get Full Book (Paid) | Download Free Sample Copy
- The Complete Java + Spring + SQL Interview Bundle Get all three interview guides in a single heavily discounted package. Get the Ultimate Interview Bundle
- Spring Professional Certification Practice Questions (250+ Questions) Validating your skills? Practice with real exam-style questions before taking the Spring Professional certification. Get the Spring Professional Questions | Download Free Sample Copy
Top comments (0)