In his 1956 account of the SAGE program, Herbert Benington highlighted the opportunity to use computers to reduce the cost of programming, documentation, and testing.
The creation of utilities, compilers, and instrumentation accounted for about half of the programming effort for SAGE. Benington had recognized that writing programs to improve developer productivity was an essential investment.
At the time, computers were costly, so the idea of making programmers more productive had far less economic weight than it does today. Programmers earned approximately $15,000 per year, and computers cost $500 per hour to operate. Now programmers cost about 70 times the cost of the computers they use. That means the value of developer productivity is worth far more today than it was in the 1950s.
Betting on software
There has been a thread of developer experience all the way back to the earliest attempts to build software at scale. Savvy organizations know that money spent on providing the right environment and tools is worth more than simply “time saved”.
There are two ways to look at software development: Cost and value. It certainly costs money to build software, so the software must provide value that exceeds this cost to be viable. Software systems are built based on the anticipation of value and survive if they manage to meet or exceed that expectation. When an organization becomes cost-obsessed with software, it suggests a low anticipated value or a realization that the value won’t be realized. It’s better to bravely abandon attempts with such a thin payoff.
The sweet spot for software is where the value is highly likely to be obtained, or where there’s a chance of it providing a huge return on investment, so that in any 10 attempts to create value with software, a single success would pay for all the attempts and return a profit.
When you consider how software is a bet, it divides software delivery approaches into two categories: cost-focused or value-focused. Traditional project management works to keep the promise of cost and timeline. Modern agile methods try to increase the probability of the bet succeeding by adjusting course as you learn more about the problem you’re trying to solve.
And here’s the crucial insight. When you manage costs effectively, the best you can achieve is zero cost. When you seek out value, there is no absolute limit to how much value you could produce. It could be twice the cost, ten times the cost, or 1,000 times the cost. There is far more upside than downside if you’re creating valuable software.
Cost-first approaches to software delivery decrease the probability of success, and one (of many) reasons is that it damages developer experience.
DevEx is economics, not hugs
For whatever reason, the universe decided that you must treat people well, whether you like them or not. Even when you examine organizational culture through the lens of cold, hard business goals, you’ll find that unhealthy cultures are less successful than healthy ones. You can be a philanthropist or a capitalist; either way, you have to treat your employees well, or it will damage the thing you care about.
Here’s a simple way it plays out.
The developers need a bit more screen real estate so they can display more information in front of them without having to switch between background and foreground apps. Additional monitors incur costs, and a cost-focused organization will likely deny the request. Developers will have a lower fully loaded cost, but produce less value. A value-focused organization sees the potential returns and their developers will get more screen space, be less frustrated, produce better work in a shorter time, and produce a lot of value.
Having an extra monitor moves the needle a little, but it’s a strong signal. Once an organization chooses between the cost or value pathways, it tends to stick to that decision. That means it’s not just monitors; it’s also chairs, code editors, refactoring tools, test tools, and automation tools. The experience diverges further with each decision made based on cost rather than value.
Another individual who understood the concept of developer experience was Joel Spolsky. He created the Joel Test as a “highly irresponsible, sloppy test to rate the quality of a software team.” The Joel Test has items like “Do programmers have quiet working conditions?” and “Do you use the best tools money can buy?”
I haven’t met Joel, so I can’t speak for his motivation, but I don’t need to know if he was motivated by kindness or cash. The result was an excellent workplace for developers and phenomenal value creation; a win-win, as Stephen Covey called it. Spolsky’s most famous products, Trello and Stack Overflow, sold for $425 million and $1.8 billion, respectively.
You don’t need to make it easy
There’s a certain amount of inherent complexity to writing great software. You must fully grasp a problem, have a strong opinion about how to solve it, and be able to execute on your plans to make it happen. Developers don’t need protection from the difficulty of building software; they need minimal unnecessary complexity from tools, processes, and the workplace environment.
There was a trend that prioritized developer comfort above all other needs, which meant providing them with frameworks to tame complexity. The frameworks made development easier, but limited a developer’s options to the extent it damaged user experience. User needs were subverted to developer ease, which is wrong and somewhat patronizing to developers.
It’s not developer experience if you’re using frameworks that improve the ease of development while annoying those trying to use the software. Developer experience means providing the right environment and tools for developers to build valuable software. Software that doesn’t surprise people with a new paper cut every 5 minutes, pushing them ever closer to demanding an alternative solution.
Think instead of how we set up a surgeon for success. A sterile room, excellent lighting, high-quality equipment, and working with skilled individuals who can anticipate and respond as the situation unfolds. Surgeon experience is centered around a shared goal of achieving optimal patient outcomes. We don’t simplify the scenario by removing things like the need to prevent infection; we make it possible to handle it well.
Developer experience is the same. We don’t choose easier problems to solve; we set developers up to succeed at solving hard problems.
Modern DevEx and Platform Engineering
With the rise of Platform Engineering, developer experience has been largely absorbed. Your organization might have a DevEx team, a platform team, or even both. Across the industry, the two teams share more commonalities than differences. From a list of 30 features offered by platform and DevEx teams compiled by DX, only 4 were exclusive to a single discipline.
Platform only:
- Certificate management
- DNS
- Networking
DevEx only:
- Developer training and education
Everything else is along the scale from DevEx to Platform Engineering, where it may be more common in one or the other, but can be found in both.
Platform Engineering and developer experience both build on Benington’s early thoughts and Spolsky’s belief that if we provide developers with the right environment and the best tools, we can amplify their skills and generate lots of value. Forming teams around this idea helps standardize and scale the approach, rather than each team being subjected to differing views based on management styles or simply not knowing what they don’t know.
The Q1 2026 DevProd headcount benchmarking report from DX highlights how well this scaling works. Rather than costing a fixed percentage of your engineering organization’s headcount, developer productivity teams scale non-linearly, with their ratio shrinking as the number of engineers increases. This makes sense, as their work is being reused, unlike approaches that work within individual teams and depend on teams having access to the necessary skills and knowledge.
| Engineers | Productivity headcount |
|---|---|
| 200-600 | 5.1% |
| 600-1000 | 4.2% |
| 1000+ | 3.49% |
That’s not to say the goal is to have the smallest possible teams. The goal is to unlock the value you create by developing software. If having half of all engineers in productivity roles resulted in the highest levels of value creation, that would be the right mix. There is likely a point of diminishing returns if you approach 10-15%, but you should be testing this by tracking meaningful outcomes for your organization.
Make sure developers have the right environment and the best tools so they can generate the most value for your organization.
Continuous Delivery Office Hours
We talked about this article during a recent Continuous Delivery Office Hours episode. Watch the episode to learn more about productivity, cost verses value, incremental improvements, and why it all has to make the boat go faster.
Watch Continuous Delivery Office Hours
