Resume-Driven Development: How 'Best Practices' Destroy Real Systems

I watched a team mass-migrate a monolithic appointment booking app to Kubernetes. Nineteen services. Service mesh. Event sourcing. The whole production.

The app booked haircuts.

Four engineers spent seven months refactoring an app that a single Django process handled fine. The Kubernetes cluster cost more per month than the app made in revenue. One engineer left during the migration. Two more followed within the year.

Nobody asked the obvious question: does a haircut-booking app need to scale to Netflix proportions?

They didn't build that system because the problem demanded it. They built it because Kubernetes looks phenomenal on a CV.

Resume-driven development

There's a name for this: resume-driven development. You pick technologies based on what impresses recruiters, not what fits the problem.

It's everywhere, and it's almost never discussed openly because admitting it feels unprofessional. But it's the root cause behind most over-engineering disasters.

Here's how to spot it in practice:

• The technology preceded the problem. Someone picked the stack, then found reasons to justify it. Real engineering starts with the constraint.
• The architecture is aspirational. The system is designed for a scale you don't have, a team size you'll never reach, or a traffic pattern you've never observed.
• Nobody can explain the trade-offs. Everyone knows what they're using. Nobody can articulate what they gave up by choosing it.
• The complexity is invisible to users. Nine months of refactoring, zero user-facing improvements. The product didn't get better. The infrastructure got fancier.

Resume-driven development doesn't happen because engineers are lazy or incompetent. It happens because the incentive structure is broken. You don't get promoted for keeping things simple. You get promoted for introducing something impressive. "We migrated to Kubernetes" sounds better in a performance review than "we didn't need to because the existing system works fine."

The one-sentence test

Here's the only rule I use now before adopting anything:

Can you explain in one sentence what problem this solves for us specifically?

Not in theory. Not for Netflix. Not for a hypothetical future. For your team, your product, your current scale.

If the answer takes three paragraphs and includes the phrase "well, when we scale..." — you're doing resume-driven development.

Some examples:

• "We added Redis because our database queries for session data were adding 200ms to every request" → real problem, measurable.
• "We added Redis because it's industry best practice for caching" → costume, not solution.
• "We moved to microservices because deploys of the payment module were blocking releases of the search feature" → real problem, specific.
• "We moved to microservices because monoliths don't scale" → received wisdom, not engineering.

The one-sentence test kills approximately 60% of "best practice" proposals on the spot. Not because best practices are bad — but because most teams apply them without understanding the specific problem they were designed to solve.

The haircut app didn't need Kubernetes. It needed one engineer who was comfortable saying: "this is fine as it is."

That takes more courage than any migration ever will.