This article is part three of three on the boom in platform engineering and its role in supporting a streamlined, positive developer experience.
In a perfect world, the developer experience would be on that is completely free of obstacles. In the previous articles in this series, I argued that supporting and improving the developer experience is a critical business requirement. To continuously improve and keep up with the constant change that typifies the cloud-native development landscape, platform engineering is–at least for now–the golden path to reducing developer toil and increasing productivity.
I’ve also countered the controversial idea that DevOps is on life support because centralized developer platforms eliminate the need for DevOps. If anything, DevOps and developers share a symbiotic relationship, and the developer platform is where their functions converge. In this third and final article of the series, I will explore this relationship, examining the considerations for how the developer experience is “platformed” and by whom.
Optimizing Developer Experience: The Circular Economy of the Developer Platform
Let’s put it this way: The more relevant and useful the developer platform, the likelier the developer is to use it. If it reduces toil, cognitive load and makes shipping software easier, the developer has more time to focus on their core task: Developing features. With intuitive, self-service workflows and all the tools developers need, they rarely, if ever, have to think about ‘the how’ of getting their software into the hands of users. And this works if and when an organization does at least a couple of things right:
- The organization prioritizes the developer experience and empowers other parts of the organization to answer the question, How can we create the optimal developer experience?
- The organization puts resources behind understanding and building the best developer experience–and that’s where both the developer platform and DevOps teams as “fixers” ideas emerge.
Does this mean the “optimal experience” can’t be optimized? Does that mean developers cannot have input into their own (or more general) developer experience(s)? No. In fact, part of what makes the developer platform idea compelling is that developers don’t have to weigh in or make decisions on the platform or tooling. Still, it’s possible to let them have that freedom if the team or organization wants to. Bottom line: There is no one-size-fits-all developer platform any more than there is a single developer experience. This is why DevOps, along with PlatformOps, is an ideal complement to facilitating the “circular economy” of the developer platform. The platform is unlikely to stay static. And to keep it dynamic and responsive to the changing needs of the developer teams using it, the DevOps teams of the future can proactively remove, recycle, repurpose and restructure the way the platform runs and what tools are available in it, automating and evaluating … almost like a feedback loop on the platform itself.
Your Developer Platform is the Golden Path to Developer Productivity
The developer experience is built around the tools and workflows developers use and, in the case of a developer platform, the tools and processes you define and provide, i.e., a “golden path” to productivity.
Whatever that platform includes, it will demand that you answer questions about what tools, processes and best practices will be most effective for delivering the optimal developer experience. For example, what and how much should you build yourself? How should the platform be assembled to best serve the needs of your developer team? What is the most effective configuration? How much freedom can or should be given to your developers, depending on your business goals and the security, stability and scalability requirements of your organization and products?
Boiling down the route to the golden path, there are three critical points to help guide the creation of an effective internal developer platform:
- Treat your platform as a product. This is key to reducing cognitive load and paving the way to shipping software fast and safely. This also means that you are guaranteed to have an MVP and alpha, beta, etc. version of the product–and subsequent versions serve their purpose temporarily but are always works in progress.
- Realize you can’t have good DevX without good UX and develop accordingly.
- Focus on workflows and tooling interoperability; that is, a developer(-led) control plane. What is going to work for developers in practice to ensure that they can focus on key deliverables? How will you gather intelligence to discover when it’s time to make changes to the platform? Who will be responsible for this?
Paving and Using the Golden Path Developer Platform Simultaneously
Developer platforms can significantly improve developer productivity and the overall developer experience. But you can’t just build a platform and hope for the best without seeking developer input or understanding how developers work. Nor can you build a platform and decide it’s finished and forget about maintenance, enhancements and inevitable change. Developer platforms don’t exist as one-and-done items on a checklist and are themselves productivity tools that are in a constant state of flux.
Misunderstanding why you would platform the developer experience in the first place defeats the purpose.
