Developer Experience Is Essential. So Why Is It So Bad?

“Experience” is a popular word these days. We live in the experience economy. Consumers expect a great customer experience. Workers demand an outstanding employee experience. Those are just a few examples of the term’s ubiquitous usage.

But if you’re one of the 4.5 million software developers in the United States, chances are that much of your experience — to use a technical term — sucks.

I’m obviously not talking about the work itself, which can be rewarding and joyful — the fun technical challenges, the adrenaline-fueled days and nights of bonding with your tribe, the unique satisfaction that comes with building something that has never quite existed before.

I’m talking about the experience of trying to get the job done with today’s toolchains. Too often, these toolchains — while containing some fantastic individual products — are poorly integrated or incomplete to enable developers to be as fast and efficient as today’s ultra-fast, DevOps-driven continuous delivery pipelines require.

The common image of a developer is someone furiously typing code as they contribute to their organization’s latest app project. And that image is true. Sometimes. Too much of the rest of the time, they’re trying to navigate a patchwork of tools while also getting stuck in the weeds of attempting to understand the code enough to proceed.

Developer-focused analyst firm RedMonk calls this “the developer experience gap.” “Most toolchains, from where the first lines of code are written through test, build, integration and deployment all the way out to production, are made up of a patchwork quilt of products and services from different suppliers,” RedMonk co-founder Stephen O’Grady wrote.

Because of this fragmentation, according to O’Grady, “developers are forced to borrow time from writing code and redirect it towards managing the issues associated with highly complex, multi-factor developer toolchains held together in places by duct tape and baling wire.”

On one hand, the world has never asked more of developers and engineers. Digitization is advancing at hyper speed. Computing has become such a vital part of our lives and every industry that “every company is now a software company” has become an oft-used aphorism. Movements like DevOps and DevSecOps keep pushing even more responsibility to developers.

On the other hand, while the industry has served up a plethora of excellent editing, testing, debugging and other automated tools to make developers’ lives easier, the result has been a hard-to-assimilate hodgepodge. The market has left it up to developers to figure it all out.

One of the huge stumbling blocks plaguing software organizations involves a critical piece that developers need at the very beginning of every project but has been missing.

As codebases have grown dramatically more complex, it is important that teams be able to familiarize themselves with the code and comprehend key information such as how files and functionality map to each other, how code changes fit into the larger architecture, etc.

But this can be extraordinarily difficult with modern codebases. Documentation is almost always lacking, there are huge numbers of confusing interdependencies and the people who wrote the code may no longer work there. The big picture is blurry or invisible entirely.

Imagine trying to build a skyscraper without a blueprint. That is essentially what software engineers and developers are asked to do. They’re given a manual with individual instructions — walk five steps, take this board, nail it to that other board vertically, take another board, nail that one horizontally — with insufficient knowledge of how one move affects the other and how they tie into construction of the broader floor or high-rise.

The eight phases of DevOps — plan, code, build, test, release, deploy, operate, monitor — need an addition: codebase understanding.

To compensate for its absence, developers have resorted to “just-in-time” cognizance — combing through codebases manually (always line by line!) to learn the minimum required to go forward, with their fingers crossed that nothing then breaks. It’s a tedious, frustrating and time-consuming exercise that gives developers fits.

If you’re one of the 4.5 million software developers in the United States, chances are that much of your experience — to use a technical term — sucks.

Not only that, but the whole endeavor frequently proves futile. If a developer is reading the code, they rarely truly know why the previous developers did what they did. I don’t know a single developer who consistently includes a comment explaining every move. And even if they did, codebases change so quickly — think of all the pull requests — that such information quickly becomes out of date.

What ends up happening is that each developer or engineer builds up their own understanding of how the codebase works… and then that knowledge walks out the door when they move to a new job.

To use another analogy, we treat code today as if it resides in a big black box. We have a variety of excellent tools to observe the black box, receive alerts when it has a problem, test it, see if it’s going to perform in the way that we think. But what is really needed is to be able to crack open the black box and grasp what’s in there.

This is not a new problem. Back in 1979, Marvin Zelkowitz wrote in “Principles of Software Engineering and Design” that “program comprehension” consumes more than half the time spent on software maintenance.

So, this issue is more than 50 years old — predating the internet. It is time to fix it. Better observability of code needs to “shift left” along with all the other functions that DevOps has pushed to development. That sure would go a long way toward improving the developer experience.