It all started when the Senior Architect dropped by the daily standup. The team lead had the backlog up on the big screen and there was a story about code quality marked "behind schedule".
"What does that story mean?" the architect asked.
"We have the static analysis tool implemented in the CI/CD pipeline, but enforcement is turned off because the findings are going to take a long time to fix." They weren't lying... Cyclomatic complexity scores of 154 (when the target is 15) are scary, and there were at least 10 different modules with methods scoring that high. Test coverage was weak... maybe 40% when the goal was 80. Duplicated code was about 4-5x the allowed 3%.
The architect frowned. "We need to start enforcing ASAP. Things are never going to get better until we develop some discipline about what we push up."
So... they turned on enforcement. No PR could be merged unless it passed the scan.
You could hear the screaming from the next county
Less than a week later, one of the developers brought up a complaint at stand-up. "The new feature is ready, but the existing code's duplication percentage is preventing us from pushing it up. Can we change the allowed percentage of duplicated code?"
Why This Is a Slippery Slope
On the surface, the request to revisit the duplication percentage threshold seems harmless. Heck, it might even seem prudent. But the question that's being overlooked in this conversation belies a deeper issue:
Your architecture's wrong.
If you remember back to your college-level Computer Science courses, you heard some terms:
Polymorphism: The ability of an entity (like a function) to exist in many forms.
Inheritance: The ability of a new class to derive from an older class.
Code duplication occurs when you have identical blocks of code in multiple places. So if you're duplicating blocks of code, you're probably not implementing with an eye toward those core principles.
You have a design flaw, and the longer you let it linger the harder it will be to address it.
The Rules Are The Rules For A Reason
The story thus far is just about a developer asking to change the rules, not realizing there was a design flaw causing the scan to fail.
It betrays a dangerous assumption, one that many software professionals make too often:
It works, and that's good enough.
I can hear the arguments already: "But Blink, the point of writing software is to get it to work! Think about business outcomes!"
But really, y'all. Good design principles are necessary to make code maintainable. To increase its longevity.
Making something that works (but is of poor quality) is short-term thinking at its best. You'll the instant win, but without any thought to next quarter. The expression "cutting off your nose to spite your face" comes to mind.
And This Is What Freaks Me Out About Agentic Engineering
If there's any community who demonstrates its absolutely fanatical dedication to short-term thinking, it's the Agentic Coding community. We're currently hearing things like "Writing Code is over".
What they're not taking into account, though, is that we're living in an artificially deflated token economy. A $200/month Claude subscription is actually spending $5000/month in token costs, but those costs are being subsidized by investment money in order to set the proverbial hook. When the VC dollars dry up... you're going to have a mountain of code that "works", but is poorly architected and full of maintenance risk. And the cost of letting AI maintain it for you just went 10x.
...And having a Claude.md file that says "You are a Distinguished Engineer with 50 years of experience architecting VueJS applications" isn't going to save you. Knowing your architecture and having your hands directly on the code is what will.
