Developer productivity has always been a hot topic of conversation, but the issue has been gaining more attention across the industry recently.
Ten years ago, the technology landscape was easier to navigate. Developers could rely on and trust in less than a handful of technology stacks, and they could become experts building enterprise applications as the stacks evolved. Today, the complexity of development environments has increased exponentially, and there is unrelenting demand for the latest and greatest applications and services.
As a developer, you’re no longer responsible just for implementing business logic; you are responsible for everything that is relevant to your application — the reason for full stack developers. Full stack developers are responsible for making the right, ideally, future-proof, choices for everything from applications to containers to pods and eventually to Kubernetes and production. While it’s true that developers typically love choices, we’re at the point where the number of options and pathways available can negatively impact developer productivity.
What Is an Internal Developer Platform?
An internal developer platform (IDP) provides a central source for engineering teams to track all the different platforms, programming languages, tools, frameworks and best practices they use. It also contains when to use each of those resources, workflow and support documents.
The ideal focus for developers, building business-relevant source code and algorithms in a programming language of choice, has almost become an afterthought. Meanwhile, configurations, declarations, frameworks and different programming languages, including service wiring and more, are consuming an ever-growing percentage of precious developer time.
All of this has resulted in a shortage of developers with the skills and experience to meet the unrelenting demand for new microservices-based, cloud-native applications. It’s very difficult to find people with the right full-stack skill sets, particularly for modern distributed, cloud-native applications. While AI promises to improve developer productivity, it’s too early to count on that. The solution, then, might just lie in internal developer platforms.
What Leads to a Developer Productivity Gap
How did we get here? Are developers spending more time supporting the environment than they are actually coding? Is the overwhelm that developers are feeling creating the current developer productivity gap, or has the developer productivity gap created the feelings of overwhelm?
In the end, what has and hasn’t led to developers’ cognitive overload almost doesn’t matter. What matters is how to reduce the load and create an environment in which developers can meet the growing demand for new products and services quickly and easily while having a great experience along the way.
There are various ways to address these challenges. Ultimately, it’s about making the right choices for the right problems at hand. If engineering teams are overwhelmed with complexity, we often are given binary choices. We can either equip them with better knowledge and tooling, or reduce complexity to a manageable point by taking it away and standardizing on fewer choices.
Either lever here can swing full spectrum from a very focused and constant learning approach to a blueprint-driven set of master solutions for certain problems. Both models are probably extremes and won’t be applicable broadly because they quickly become roadblocks either way.
Introduce Developer Guardrails in the Form of IDPs
I advocate for something I like to call guardrails. What developers really need in order to be productive is an avenue of approved methodologies and technologies, a curated collection of products and processes from which they can pick and choose and mix and match for the use case in front of them.
For example, developers working in the automotive industry are focused on creating applications for building cars and not on creating e-commerce applications. It makes sense, then, for these developers to have the best tools and frameworks for creating automotive-related applications and not have to worry about tools for building e-commerce apps.
This is what an internal developer platform does. It provides a central source for each of the different platforms and frameworks required for each product, along with best practices.
Developers need a narrowed-down but solid set of technologies and tools proven to get the job done. Even better when these tools are already flavored with specific templates that capture best practices and experiences from similar teams.
In fact, experimentation, especially in mature industries, shouldn’t be the biggest challenge. Rather, the biggest challenge should be combining available blueprints, master architectures and references in a way that balances flexibility and structure to give developers the velocity they need.
Organizations are trying to accomplish this in a variety of ways, including intranet sites and documentation-based systems. Both are fine first steps, but internal developer platforms and tools such as Backstage take the concept to the next level by providing specific infrastructure plug-ins and software components, as well as catalogs that provide an overview of everything that is available to developers. These knowledge lakes turn from portals to a solution space enriched with the right set of technologies and, ultimately, to IDPs.
IDPs Reduce Developers’ Cognitive Load
IDPs integrate into existing workflows and are built by platform teams, which treat the platform as a product that will be continuously updated and improved. Using an IDP, developers can efficiently request resources, spin up fully provisioned environments and set deployment automation, as well as start applications and services from scaffolding templates with relevant cross-functional aspects (such as security and logging) already built in.
These templates are often called “paved avenues” or “golden paths.” Integrated into an IDP, golden paths are pre-architected and supported approaches to building a specific piece of software or a service. Golden paths’ repeatability reduces developers’ cognitive load and enables them to channel their energy into writing source code for truly innovative applications and services.
Spotify, which coined the “golden paths” term, first started using the framework in 2014 to provide better alignment in developer tooling. Today, golden paths provide Spotify developers with development guidance and function as easily discoverable tools.
Spotify’s first golden path was for back end engineering. Now there are paths for client development, data engineering, data science, machine learning, web and audio processing. On a wider scale, the golden path approach makes it easier to onboard new members to engineering teams and introduce completely new products into an existing technology landscape.
Don’t Wait for AI to Solve the Developer Productivity Gap
Predictive and generative AI are also expected to play a big role in increasing developer productivity. It’s still too early to determine just how AI will work in this context and what organizations will need to do to support security, privacy and compliance, but I can see a future where there is an AI “birdie” sitting on my shoulder walking me through every aspect of the development cycle.
With that said, don’t wait for AI to close the developer productivity gap. Prepare proactively to leverage AI, but while AI has a great deal of potential, there is still a large margin for mishaps. The technology can go only so far.
There’s no time to waste. Every minute that developers don’t fully work to their potential is a huge competitive disadvantage. In the end, developer productivity and satisfaction are the only metrics that really matter. Only happy developers successfully deliver high-quality applications and services into production.
