When I ask developers to name their biggest threat to developer experience, productivity, and software quality, the answers are often focused on a single challenge that only ever seems to increase in difficulty.

Software complexity.

It makes sense that software would be more complex today than, say, 20 years ago, when I first started my career as a developer. But when I try to pinpoint the specific areas of software development that deserve the most blame, one area in particular involves the number of dependencies in which developers are dealing with.

Twenty years ago, I would say that 85% of the code that I and my team were building was proprietary code. We were building the business logic. However, when you look at what many developers do today for a given application, it’s the opposite. Their proprietary code might only make up 15-20% of their code base, while they rely on 80-85% of code that comes from libraries, open source, and other external components. It’s not uncommon for developers to rely on hundreds, if not thousands, of libraries that they need to learn about, so that they can fully understand dependencies that scenario creates. The same goes for an ever-increasing number of APIs.

When a developer is mapping out how they’ll build a new application, and they start looking at leveraging say, Stripe and its API for payments, Algolia and its API for search—and there will be many others – they need to explore and really understand those APIs at a deep level. They then have to build on top of them. They have to test them, and test them again whenever they change; the dependencies and complexities quickly begin to compound.

And the complexity hardly stops there. Think about the number of devices that software needs to run on. Will it provide a great user experience on web and mobile? Which mobile? Android and iOS? Which versions? 

Oh, and I almost forgot. Not only are developers today expected to solve the challenges above and a million others, they’re constantly being asked to do those things faster. How many times a month, week, or day are you currently deploying? Is there an expectation or a goal for that number to increase in order to get innovation into the market before your competition? If there is, remember to not let software quality slip! 

This is the level of complexity that threatens developer experience and productivity, while increasing the likelihood of burnout and the erosion of software quality. It’s overwhelming.

How do developers deal with this? The good news is there are countless tools out there to help them automate time-consuming development and testing activities across their pipelines. It’s common for developers to leverage 15, 20, or more of those to aid them in those efforts, but the context switching alone between that many disparate tools introduces its own complexity.

Inspiration from the auto industry

The problem I’ve described above, thankfully, is not insurmountable, and we actually know what’s needed to solve it: greater visibility and greater intelligence. 

When we think about greater visibility and intelligence, what do we mean? Think about the electronic stability program (ESP) of a car. (This is also sometimes referred to as “electronic stability control.) With ESP, it’s all about the speed of feedback, and it’s not hard to understand why this would be not just “valuable,” but critically important in an automobile. ESP takes continuous measurement of the rotating speed of each wheel, so that if your car starts to drift, it can adjust the speed of other wheels that need to rotate at a speed that keeps you on the road and not in a ditch.

ESP doesn’t replace the driver, their focus, and ability to process rapidly changing information, road conditions, changes in weather, and other external threats to themselves and to the cars around them. ESP is there to augment the driver, not to replace them.

This is very similar to the level of visibility—and the speed at which it can be provided to development teams – that is needed in the software industry as well. The entire premise around DevOps is to equip teams with an automated, continuous feedback loop that removes manual handoffs that prevent the safe acceleration of development and deployment. 

When I think about the premise of “developer visibility,” I think about the way a car is equipped with technologies that don’t just make ESP possible, they empower the driver to maintain control and to safely accelerate when opportunities arise to do so. Ideally, we want to create more opportunities for acceleration within development teams—even as the complexity of their code continues to increase in complexity.

Developer visibility allows teams to not simply look at the current status of their application, which in many cases is actually the past status, depending on how long it took to run, share, and gain insights from that observation or report. “Real” visibility is the ability to look ahead in order to mitigate problems, or even better, see the likelihood or risk of a potential problem before it’s even formed and to eliminate its root cause before it even has a chance to form.

The Ultimate Driving Developer Experience

I hope BMW doesn’t mind me augmenting their tagline. Prioritizing developer experience isn’t a new concept, but one area that may have been missed is the “why” behind why developer experience is so important. It’s not only to make sure that developers love their jobs, though that’s certainly an important part of it! But the reason why it has become an area that forward-thinking companies are investing in so heavily is that when you have a top-notch developer experience in your organization, those developers are then able to better prioritize your customers’ user experience. Think about it. If a developer has earlier and greater visibility into threats and potential threats to your users, they’re able to prioritize what needs to be fixed, tested, and deployed right now and what perhaps doesn’t need that level of immediacy. What region are we seeing a particular error in? Which versions are experiencing problems, and which ones aren’t? Where is greater test coverage mandatory, and where is our current percentage perfectly fine? 

What we need to enable developers to do is to be proactive and predictive at the same time. This is done by helping them connect the dots between pre-production and what’s happening in production, or again, what’s likely to happen in production – being that out in front of things. 

Maybe don’t “automate all the things”

Automation deserves a lot of credit for improving the lives of developers. However, there’s been a push over the years to think that automating “everything” (it’s never actually everything) is the ultimate goal. If the ROI of automating 50% of our software tests gave us “X” in return, then the ROI of automating 100% of our tests must be at least twice that, right? Not necessarily. There are plenty of things that don’t actually provide a positive ROI when automated, and the effort to set up that automation can put you into the negative. Maybe you do end up with thousands upon thousands of automated tests when you’re done, but what if those tests are “brittle,” “flaky,” or if your application changes so frequently that those tests immediately fail the next time you run them on the new version? Even if they didn’t take long to initially set up, the time it takes to maintain them over time can quickly add up.

When we think about developer visibility, and how it relates to ESP, or the automated nature of a mature DevOps pipeline, it can feel like “full, 100% automation” is the goal, when it’s not. The goal is to have technologies in place that can help you identify the right tests to automate. Which tests are critically important, but currently take too long to execute? Let’s get developers the right diagram of a testing pyramid that divides things up into the most effective ways for their unique needs, as well as those of their customers. There’s never time to test “everything,” and thankfully nor is there always a need to test everything.

The best output comes from the best input

The visibility of what makes up that “right” formula of tests, meaning being able to identify the tests you can get rid of and not continue to run, is critically important for teams that aren’t just looking to accelerate the delivery of innovation, but to also increase quality along the way. 

When I’ve asked other developers what their primary goal is at work, what it is they really want the opportunity to do, the answer, more times than not, has been “to deliver software that our customers want to use and get the most out of.” The way to do that, in every release, is for developers to gain visibility around what will and won’t improve their current processes. What context around development, testing, pre-production, and production environments will provide real intelligence, and what context is just noise? Did I test the right areas of our codebase and did I use the right tests in that effort?

These are all great questions to ask, and don’t get me wrong, developers have been asking these questions for a long time. But as software complexity continues to grow, so do the places where invaluable context and intelligence grow as well. Greater visibility, faster visibility, and ultimately, continuous visibility into those areas will give developers the answers they need to do the work they love to do.