I have good news and bad news. 

The good news is that developer experience (DevEx) is gaining recognition and that many organisations are now forming platform engineering teams and building internal developer platforms (IDP). In fact, Gartner predicts that by 2026, 80% of large software engineering organisations will have established platform engineering teams.

‍

The bad news is that DevEx has a long way to go. A recent survey of more than 2,000 developers by Atlassian found that 69% of developers lose eight or more hours a week due to inefficiencies. And the top reason for lost time? 59% of respondents answered with technical debt. Stack Overflow’s 2024 annual developer survey echoed similar sentiments with technical debt (62.4%) ranked as the top frustration, followed by system reliability (31.2%) and tech stack complexity (30%). Yet another recent survey by Harness found that developers manage an average of 14 different tools and that, due to the multitude of tools they have to juggle, it takes a new developer an average of 100 days to complete onboarding.

It’s clear that infrastructure is one of, if not the biggest barrier, to the ideal developer experience. In my experience, these three issues are enough for any developer to tear their hair out:

Lack of self-service access

Many organisations have centralised IT or platform teams that manage cloud resources to maintain control over costs, security, and compliance. This can lead to restricted access for developers, as these teams may fear losing control if developers are allowed to provision resources independently. This can result in weeks-long delays, which is simply unacceptable to any fast-moving team. The desire to prevent bottlenecks and accelerate the development process is itself the impetus for many teams building IDP today.

Proprietary tools

While hyperscale cloud providers such as AWS and Azure support a broad ecosystem of open-source tools, developers are encouraged to use the tool that’s native to that provider for compatibility and stability reasons. For example, using AWS Step Functions or Azure DevOps over Argo CD. While many developers can adapt with proper training and time, it is still an unnecessary burden on already overworked teams. Developers should not have to relearn a whole suite of tools every time they switch jobs or projects.

Customisation and service limits

Cloud environments (especially public clouds) can limit developers' control over their infrastructure. For example, developers often need to tailor their hardware, software, and network configurations to optimise performance and reliability for their CI/CD pipelines. However, this level of customisation is often not possible in public clouds, which operate on standardised infrastructure.

Cloud service providers’ service limits can also restrict flexibility and adaptability, which are often crucial for innovative development work. For example, with AWS, the default limit is 20 EC2 instances per region and 5 Elastic IPs per region. While these limits can sometimes be increased by request, they still impose constraints on how developers can scale their applications.

Of course, there are many more challenges. But it’s obvious that we need platform engineering teams to relieve developers of this burden.

When it comes to DevEx, nothing else matters until the core challenge of infrastructure is solved. It’s not about adding more developers or enforcing work-life balance, or improving documentation, though these are all important things that must be addressed.

To me, the ideal developer experience is simple: Familiar (and open source) tools, unlimited freedom to tinker, and zero infrastructure management.

‍

‍