Death by overhead, a story about unhappy developers

Developers today are mired in inefficient tools, processes, and workflows, but it doesn't have to be that way.

I've had a number of lengthy discussions recently about the problems developers face, and more specifically why they face them.

A significant reason so many developers are unhappy and sometimes unproductive in is because of the way our industry thinks about the role.

As an industry we've consistently undercut the value of developers, tried to manage them using manufacturing and government-derived processes, thrown misguided tools at the problems, and developed pseudo-standards based on the working practices of a handful of companies.

This is wrong.

Development is not like any other job or domain in existence. It is not linked to physical goods the way engineering or architecture is, it is not often constrained by the supply of raw materials like manufacturing. It is it's own thing and needs to be treated as such.

Evidence and practice suggests that where we need to improve most isn't in the code itself, but rather in the ecosystem and tooling around it. We need to move away from developers and other technical roles breaking flow to update a wiki, using substandard ticketing systems to gain access to critical resources, and navigating the mountain of the paper cuts that come with being a software developer in an enterprise.

Put another way, how much time is lost to bureaucracy, the tyranny of outdated tools, and information gaps within enterprise development teams?

Enough that developers on average only spend 14% of their time writing code.

14%

Sure, there is never going to be a scenario where 100% is practical, but there is more than ample room for increased efficiency.

That would make everyone happier.

We reviewed industry reports to determine if what we've experienced, and what others are living today, is off the mark. Sadly, it isn't.

The lowest developer efficiency numbers we've seen hover around 4% and the highest 27% (an internal estimate). Much of the overhead is related to thinking about software in a similar vein to a manufacturing process. But developing and operating software isn't a manufacturing line. In fact many manufacturing businesses are trying to be more like software shops. Funny isn't it?

So from here on out let's build with a new mental model of what our workflows should look like. No more manufacturing standards or haphazard tool deployment. No more information silos. And absolutely, under no circumstances, do we use tickets or out of date wikis for knowledge transfer. Live systems are the source of truth, use them.

There should be very few steps of the life-cycle where a developer or other engineer need to break flow to search for information or fill out information requests. The information needs to be in their tools, within their current context, and immediately at their fingertips at all times.

It's scary to disrupt what works, but what we have been doing has hit a breaking point. The scale and speed of modern software development is just too immense.

There is a better way, and we are building it.

Sources & further reading:
https://drpicox.medium.com/developers-spend-less-than-10-of-time-coding-51c36c73a93b
https://www.software.com/reports/code-time-report
https://stripe.com/files/reports/the-developer-coefficient.pdf