Developer tooling has come a long, long way in the past couple of decades. Syntax highlighting, linting, beautiful and easy-to-use IDEs with debugging features build-in, hot reloads, automated tests and lots and lots of other ideas and tools have made the life of a software developer a lot easier, and the field of software development more accessible.

But still, large differences in productivity among developers exist, and a large part of that is related to tooling. Developers spend a lot of time taking care of their tools, troubleshooting their setups, and going down rabbit holes of configuration and dependency management. And there are lifetimes spent waiting: waiting for builds or tests to finish.

This begs the question: what can we do about it?

Why do developers still spend so much time not writing code?

It all goes back to the saying “complexity kills productivity”. Software development is a complex undertaking, and developers are expected to deal with a lot of the complexity themselves. One example: many developers are expected to run the applications they develop on their own workstations. Depending on the complexity of the application, the tech stack used (which relates directly to the maturity of available tools), as well as the quality of scripts (which are usually developed in-house) to build and deploy the application locally, this can be very complex. Which, you guessed it, kills productivity.

Developers are expected to master a wide range of technologies which are not directly related to software development. In simple cases, it could “just” be docker: if the developer is lucky enough to be working on a fully containerised application, knowledge of docker is likely to be a prerequisite to be able to run the application locally.

But Docker is a complex tool.

Many developers would have a lot more time for writing code if they did not have to learn, use, and troubleshoot docker.

This is not a rant about docker: it's a great technology and I’m a big fan. I just use it as an example of the many different tools developers are expected to know in order to do their job.

What can we do about it?

Honestly, I think a big part would be a shift in culture, which would lower expectations towards developers. A mindset in which developers, much like all other business functions, are equipped with tools which enable them to do their job without having to deal with the underlying complexity of the enabling technology. Nobody expects an HR person to know a lot about IT, after all: they are equipped with software that enables them to do their job without knowing about the underlying cloud infrastructure that hosts the HR software, or the containers in which it runs.

The problem with this is that developers build products that other people need to be able to run and use. DevOps was a whole movement that preached the exact opposite: bringing operations and developers closer together, lowering boundaries, and building expertise in both development and operations. The perfect developer would also have deep expertise in operations, and the perfect operator would have deep expertise in development, they would work in cross-functional teams and everybody would do all the jobs, basically.

This sounds again like a rant :)

DevOps is great. It just doesn’t work. What we have seen is that in most organizations, DevOps teams were formed which operated in much the same siloes that operations teams used to work in before, and nothing much really changed.

For some, DevOps works, because they embraced not just the job description but the mindset behind it. This can lead to highly productive engineering teams.

However I think that this is something that is only accessible to very experienced, very smart and top-performing experts who can absorb and apply the huge breadth of knowledge required to be an expert in both operations and development.

For the rest of the world, I think a different kind of mindset is required. I also think that it is already on the horizon.

Platform engineering as a way to remove complexity from software development

Platform engineering is often called the evolution of DevOps. I think it isn’t really an evolution but a completely different approach. It focuses on providing self-service tools to developers that enable them to do their job - i.e. write code - without having to bother with all the complexity of developer tooling.

The biggest change in mindset in this approach is that developers are no longer expected to do everything themselves. Platform engineers are seen as a support function of the software development teams and they are themselves specialists in platform engineering, not software engineering.

They have to understand the work of developers to the same degree as software developers should understand the users of the software they develop. But there is no more talk of cross-functionality and teams consisting exclusively of all-knowing unicorns.

It doesn’t even need a full-blown platform engineering team to start moving in this direction. Recently, there has been an explosion in interest and products for Cloud Development Environments (CDEs), which provide ready-to-go work environments for developers. Just not having to troubleshoot local development environments is already a big step in the right direction by removing complexity and hassle from developers.

Conclusion

Division of labor and specialization are forever in conflict with collaboration and cross-functional expertise that tends to nurture both innovation and quality. Neither extreme is a good idea: neither having people develop deep expertise in tiny areas, nor having people know a little bit about everything will produce good results.

The problem we face as engineering leaders is to know where to set the boundaries, and how much to expect of our people. I believe that collaboration between teams with clearly described functions and clear boundaries leads to the best outcomes.

Platform engineering teams supporting software developers with self-service tools seems to me like a setup that could work: it empowers developers while reducing the mental load on them. It also creates a rewarding and interesting job function: platform engineering might be one of the most complex and yet rewarding job profiles out there. It requires working with cutting edge technology and building products that the highly discerning user group of developers likes to use.