“Technical debt” might be one of the most successful terms ever coined in software engineering.
Not because it solved the problem. Technical debt is still everywhere. But it fundamentally changed the conversation. Before the term existed, engineers struggled to explain why seemingly harmless shortcuts eventually become expensive. Calling it technical debt gave business leaders a language they already understood. Debt accumulates interest. Debt carries risk. Debt demands attention.
It was a brilliant metaphor. The metaphor didn’t eliminate technical debt, but it changed how organizations think about it. Today, no serious engineering organization questions whether technical debt exists. The conversation has shifted from Is this a real problem? to What should we do about it? That’s the power of language. Today, our industry has another equally pervasive problem.
Developers spend their days fighting slow build systems, brittle internal frameworks, unreliable tooling, unnecessary processes, endless context switching and organizational friction. Every one of these things quietly reduces an organization’s ability to build great software, yet we rarely talk about them as strategic business problems. We have a name for this.
Developer Experience.
And I believe we’ve chosen the wrong one. Not because the underlying idea is wrong, but because the name fails to communicate what is actually at stake.
The Wrong Conversation
At first glance, Developer Experience seems like a perfectly reasonable name. After all, nobody questions the importance of Customer Experience. Entire organizations are built around improving it.
So why hasn’t Developer Experience had the same impact? I think the answer is surprisingly simple. The relationship between customer experience and business performance is obvious. Happy customers buy products, remain loyal and recommend them to others. Executives instinctively understand why customer experience deserves investment. The relationship between developer experience and engineering performance is far less obvious.
When executives hear Developer Experience, many unconsciously categorize it as an internal quality-of-life initiative. Something that would be nice to improve once more important business priorities have been addressed.
Ironically, the same executives care deeply about engineering performance. They worry when expensive engineering teams deliver slowly. They worry when quality declines. They worry when innovation stalls. They just don’t naturally connect those outcomes with what we currently call Developer Experience. That’s the problem. The name hides the real business impact.
As a result, conversations about developer productivity often drift in an unhealthy direction. Instead of asking how to build an environment where engineers consistently perform at their best, we ask questions like:
- How can we measure developers?
- How can we increase output?
- How can we ship more features?
- How can AI make developers faster?
These questions all assume performance is something we extract from people. I think that’s backwards.
Performance Is an Emergent Property
Imagine an elite sports team. Nobody expects world-class athletes to win championships simply because they have better shoes. High-performance organizations invest across the entire system:
- Coaching
- Training
- Nutrition
- Recovery
- Medical care
- Sports psychology
- Team dynamics
- Equipment
- Leadership
- Purpose
No one believes any single investment creates champions. Performance emerges from the interaction of the whole system. Software engineering is no different. Good tooling matters. Fast build systems matter. AI coding assistants matter.
But so do:
- Autonomy
- Ownership
- Trust
- Sustainable pace
- Customer proximity
- Protected focus time
- Psychological safety
- Fast feedback loops
- Cross-functional collaboration
- The freedom to improve the system itself
These are often discussed as independent initiatives. They’re not. They’re all investments in engineering performance. This holistic reality is precisely why frameworks like SPACE exist. Developed by researchers from GitHub and Microsoft, the SPACE framework—which evaluates Satisfaction, Performance, Activity, Communication, and Efficiency—was built to stop organizations from falling into the trap of measuring developers purely by raw output (Activity). It proves mathematically and empirically that Performance and Efficiency cannot exist without Satisfaction and effective Communication.
When we look at software through the lens of SPACE, we see that developer well-being and system performance aren’t competing priorities—they are interdependent variables of the exact same equation. That’s why I believe Developer Experience has unintentionally constrained the conversation. The name naturally draws our attention toward tools and developer happiness, when the real objective is building an environment where exceptional engineering performance emerges naturally.
The Interest Rate Nobody Talks About
Technical debt is usually discussed in terms of its external cost:
- Slower delivery
- More production defects
- Operational incidents
- Higher infrastructure costs
- Lost customers
These costs are real. But technical debt has another interest rate. The human one.
- Every day spent fighting the tooling.
- Every obvious refactoring postponed because “we don’t have time.”
- Every unnecessary approval.
- Every layer separating engineers from customers.
- Every interruption.
Every reminder that shipping today’s feature matters more than improving tomorrow’s system. None of these destroys motivation overnight. They compound.
Eventually developers stop improving the system. Not because they stop caring. Because the system slowly teaches them that caring isn’t rewarded. This is the part of technical debt we rarely discuss.
Technical debt doesn’t only accumulate in software. It accumulates in people. Developers gradually lose ownership. Curiosity becomes compliance. Craftsmanship gives way to expediency. Enthusiasm slowly erodes into indifference.
Those costs rarely appear on a balance sheet, but every engineering organization eventually pays them.
Maybe We’ve Been Optimizing the Wrong Abstraction
If I asked an executive whether engineering performance matters, the answer would be immediate. If I asked whether developer experience matters, the conversation would probably require an explanation. Those are fundamentally different starting points. The irony is that we’re often talking about exactly the same thing.
A developer who spends hours waiting for builds, navigating brittle internal platforms, fighting legacy code, requesting permission for obvious refactorings, and constantly context-switching isn’t simply having a poor experience. The organization is paying a massive price to hold them in that environment.
Maybe we should stop calling it Developer Experience and start calling it Developer Carry Cost.
In finance, Carry Cost is the ongoing expense required to hold and maintain an asset while waiting for it to generate a return. If you buy a physical or financial asset, you don’t just pay for the acquisition—you pay the carrying costs to keep it operational.
In software engineering, the developer is the primary asset. Software is merely what that asset produces.
Now, framing human beings as “assets” and human frustration as a “carry cost” might feel uncomfortably cold—especially to engineers who are tired of being treated like cog-in-the-machine resources. But that discomfort is precisely the point.
The comfortable, polite language of “developer experience” and “well-being” has failed us. It allows leadership to relegate systemic engineering friction to an HR quality-of-life initiative—something to look into once “real” business priorities are met.
When developers spend 30% of their day battling broken tooling, slow pipelines, and administrative drag, that isn’t just friction—it’s an astronomical Developer Carry Cost. You are paying top-market compensation for a high-value asset, while burning a third of its capacity just carrying it through a flawed system. Worse, under these conditions, human beings eventually disengage. They check out. The asset stops yielding not because the person lacks talent, but because the environment has worn them down.
Technical debt is often just the visible symptom on the codebase. Developer Carry Cost is the actual disease on the balance sheet.
We don’t need softer words; we need language that immediately communicates what is at stake to leadership. Investing in the engineering environment isn’t an internal luxury or an employee perk; it is a direct investment in lowering our Developer Carry Cost so our most valuable people can actually do their best work.
Why do so many organizations still struggle with developer experience? What do you make of the term Developer Carry Cost? Can you think of a better alternative? I’d love to hear your thoughts in the comments.
답글 남기기