Developer Experience: The Next Steps in the Cloud Maturity Curve

Define responsibility: Shift left but with the right ingredients

Much has been said about shifting left toward the developer, but as Kelsey argues, this shift involves everyone in the pipeline. There are times when only a developer knows what dependencies they actually need, and in many cases only they can resolve those dependencies. But what about dependencies like a security issue or a problem that violates company policy? It's not just downstream software bugs any more but instead a chain of information that may be outside the developer's scope but still needs to be considered, e.g., compliance, security, etc. The earlier in the ideation process a developer gets all the information, the better prepared for responding to it even if a developer isn't necessarily the person responsible for something like the security of dependencies.

This is where the idea of defining responsibility enters. Who is responsible for each step, and the consequences of the steps taken? Kelsey highlights software bills of materials (SBOMs) as an integral part of securing software development and deployment supply chains. He goes on to advocate for the importance of being very clear about what you can do at every step, even at an informal level before you adopt an SBOM or : "If you're the developer, you will have some responsibility for the "ingredients" you add to the mix. You will be asked to understand and answer for some of the choices you make. And beyond the developer, everyone needs to be aware of their responsibility in that pipeline."

Centralize: Defining how to deliver on a promise

Infrastructure is difficult, and none of it was built with developers in mind. Kelsey, in a 2019 Tweet and in discussion, reiterates that while Kubernetes gives you more infrastructure and better APIs, it's still a last-mile technology. A developer needs a control plane, or something centralized, that they can trust as a deployment target. That is, the dev builds their code, makes sure it's packaged correctly, makes sure the dependencies are there to make it run… but how does it get deployed? Rather than needing to run deployment, the developer just needs to trust that if they give you their application and a bit of configuration, the platform should be able to do just that.

"It goes back to Mark Burgess's Promise Theory: We need a way to make a promise. And then ensure that the machinery in the background will run 24/7 to try to keep the promise true. Whether you like YAML or not, it just doesn't matter as a human being, you need to ask for what you want the infrastructure to do. It can be XML. It can be JSON, it could be a text file. The world will sort it out. There's many spoken languages too. Humans have to articulate their desire to the infrastructure. This is where we think, 'Oh, having something where a user can write down what they want, submit it to a control plane, which can preserve the state and then have actuation loops behind the scenes converge and keep it true.' The control plane concept or experience is the evolution of this, where things take off for all sorts of infrastructure platforms. You now have a central place to hold state, converge it and keep it true over time. Kubernetes just happens to be what we consider a universal control."

Empathy: Understand the experience before and while coding

What does it mean to have empathy during the entire life cycle of an engineering process? Kelsey highlights what he calls "empathetic engineering", meaning at a high level that engineers, and companies more broadly, use their own product to, more or less, understand what it is like for a user and make it more reliable. The ultimate idea is to approach software design with empathy for the user, i.e., what will the user do with this software, and if they can't accomplish that goal, it needs to change.

What better way to embed this empathy than to get hands-on with the software, and earlier still, become comfortable with the "human stuff", like customer service and experience. "There was a time when you could get pretty far as a developer without ever using your own product, but it does not work any more. Once you've experienced an application that makes you think, 'Wow, someone thought about how I would use this when they created it; it's intuitive, it's frictionless', you start to see the difference between end-to-end empathetic engineering and the kind of development that feels like no one tried it out at any point in development."

Take time for research and education: Building on empathy

"At some point, we need to realize that writing code is the last part of the software development process. Deciding what to build is where time, attention, and work should be done. How do you learn what to build?" Kelsey expands on the empathy concept, exploring how developers could benefit from thinking about psychology, how people behave, how they want to behave, what people's needs are.

"If you get really good at the human side of it, I think you will end up writing much better software." Kelsey cites the importance of pre-development research and peer review, but most people, unfortunately, are not given time for empathy. Instead, they are handed a deadline and a feature and told, "Go build it", but the developers have never built such a thing before. "It ends up that you can go along for years creating something that you think is needed only to go to a conference and find out it already exists. If developers had adequate research time, they'd know not only what is available in the world but could make more informed decisions about what they intend to build."

Conclusion: Converging on maturity — Answering for what's actually in the software

Getting to a place of maturity will rely on the aforementioned education, giving developers time and space to research and understand just who they are building software for, and figuring out responsibilities. But responsibility for who does what is one thing, but then the "buck stops here" accounting for what is actually in the software and its secure supply chain is a big next step in the maturity curve.

"The software supply chain is getting a lot of attention these days. That is, a reproducible bill of materials... what's inside your software, all of its dependencies and its transient dependencies. The industry is beginning to mandate that we can go back and prove what's inside of the software that we are building. For a developer this means moving away from importing random libraries and instead becoming responsible for what they include and its provenance. We need to get much better at making clear who wrote this library, who contributes to this library and what are its transient dependencies, because the developer is now the baker in this equation pulling in ingredients that may or may not be good for people on the other side. Education, centralization and discipline will help us really focus attention on what's in our software. And knowing that we have the power, control and responsibility to make sure that only the things that are necessary to be in there."