Ignoring Technical Debt for the New Shiny Thing

Why do developers love new frameworks? Because it's easier to create new technical debt than it is to pay off the old

Hide that 12-line pure function - once the OOP task force finds it, it’ll be reborn as a TransactionExecutionStrategyFactoryAdapter and we’ll spend Q4 on-call untangling the dependency graph

After 15 years of AbstractFactoryFactoryBuilders and enterprise Java, you realize the real design pattern was Stockholm Syndrome all along - you hate OOP until someone suggests a 500-line procedural function, then suddenly you're defending SOLID principles like they're your firstborn

The irony here cuts deep: after decades of 'everything must be a class' dogma leading to AbstractSingletonProxyFactoryBean nightmares, we've come full circle to discover that sometimes a function is just a function. The UN peacekeepers represent every senior engineer who's had to maintain a codebase where someone put a single static method inside a class inside a package inside a module 'for organization.' Meanwhile, the OOP evangelist is still out there, insisting your pure function needs to be wrapped in a Singleton with dependency injection, because 'what if you need to mock it later?' Spoiler: you won't, and now you've got 47 lines of boilerplate for what could've been `const add = (a, b) => a + b`

Nothing says SOLID like wrapping a pure function in a UtilsService and an IUtilsService so the DI container has something to do - congrats, you just shipped procedural code with extra indirection and a mock tax

Architecture police: “Open up! That pure function needs a class!” Two PRs later: IFoo, FooImpl, FooFactory, a @Component injecting zero state, and a proudly anemic domain model

Because nothing enforces separation of concerns like a blue-helmet regime change in your codebase