Resume-Driven Development

What It Is

Resume-driven development is the practice of selecting technologies, frameworks, or architectures based on how impressive they will look on the chooser's resume or how trendy they are in the industry, rather than on whether they actually fit the problem. The newest database, the buzziest framework, or the most fashionable architectural style is adopted because it advances a career or satisfies curiosity, not because the system needs it.

The motivations are understandable — engineers want to stay marketable and work with interesting tools — but the system and the team bear the cost.

Why It Happens

• Career incentives. Marketable skills come from working with in-demand technologies, so engineers seek them out at work.
• Hype and novelty. New tools attract attention, and adopting them feels like staying current.
• Boredom. Proven, "boring" technology is less exciting to work with than the latest thing.
• Weak selection process. No disciplined evaluation of fit, so preference fills the gap.

Why It Hurts

The chosen technology often does not fit the problem, introducing complexity the team must fight rather than leverage. Bleeding-edge tools bring immature ecosystems, sparse documentation, and unstable APIs, raising maintenance cost. The team accumulates a sprawling, inconsistent stack as each project chases a different trend, multiplying the operational and cognitive load. When the original advocate moves on — resume duly enhanced — the organization is left maintaining an exotic system few understand.

Warning Signs

• Technology choices follow industry hype rather than stated requirements.
• The stack churns as each new project adopts a different fashionable tool.
• Justifications emphasize how interesting or cutting-edge a tool is, not how well it fits.
• Experimental adoptions are abandoned once the novelty fades.

Better Alternatives

• "Choose boring technology." Prefer proven, well-understood tools and spend novelty budget sparingly.
• Fit-for-purpose selection. Evaluate options against the actual requirements and constraints.
• Architecture decision records. Document why a technology was chosen, forcing justification beyond appeal.
• Proof-of-concept spikes. Validate that a new tool genuinely solves the problem before committing.

How to Refactor Out of It

Introduce a disciplined selection process: every significant technology choice must be justified in an architecture decision record against the real requirements, constraints, and team skills. Adopt the "choose boring technology" principle and treat each novel choice as spending a limited innovation budget. Validate new tools with small spikes before betting a system on them. Align incentives so engineers can grow their skills through depth, side projects, and well-scoped experiments rather than by reshaping production systems. The aim is a stack chosen for the problem, not for the portfolio.