Refactoring

There is a file in the MongoDB codebase that has been touched 62 times in the last year. It is 2,273 lines long. Its cyclomatic complexity is 926 — in a codebase where the average is 53. replication_coordinator_impl.cpp Every engineer who has worked near the replication layer knows it. The name alone is enough to produce a familiar reaction: a slight tension, a quick mental calculation of whether the ticket they just picked up is going to touch it. ...

You just fixed a bug in the payment module. Simple enough — an edge case in the calculation logic. You changed three files: the payment handler, a date formatting utility, and a config loader. Those three files have nothing to do with each other. You know that. You’ve always known it. You fixed the bug anyway, committed all three, and moved on. Because that’s just how this codebase works. Your import graph is lying to you When we talk about coupling, most developers think of import statements. You open a file, you look at what it imports, and you draw a mental map of dependencies. Clean Architecture tools do the same thing — they trace the explicit links between modules and draw you a diagram. ...

“Just add a field? It’s a 20-minute job.” We’ve all said it. And three days later, you’re still knee-deep in a labyrinthine codebase, the ticket is still open, and your motivation has evaporated somewhere between burnout and quiet resentment. It’s not just about the task. It’s about the feeling that you aren’t building anymore. You’re just… patching. ...

In my previous post, I argued that full specification fails with AI — and that component-based architecture with clear interfaces is the right model. Since then, several readers pointed me to a similar argument by Javi Lopez, who draws a sharp parallel to the CASE tools of the late 1980s: the same promise, the same illusion, a new mask. Lopez is right. And I want to go one step further — not just to say what goes wrong, but to show what it looks like when it goes wrong, and what it takes to recover. ...