Developer platforms are one of the most important elements of platform engineering, an emerging practice which focuses on providing software developers with all of the self-service toolchains and workflows they need to write, test, and roll out their code. Platform teams build paved roads or golden paths to simplify the route to software delivery.

A well-designed and implemented internal developer platform can supercharge your developers by giving them the tools they need to deploy their code, encourage seamless knowledge sharing, and enable developers to focus on higher value inner loop tasks. Let’s dig in.

The challenge of knowledge reuse

As an organization gets bigger, knowledge sharing and reuse can become incredibly challenging.

There are various scenarios where software engineers can reuse knowledge, ideally within the codebase itself. Beyond reusing existing code, you may also want to promote the reuse of certain engineering guidelines and standards. 

Often, these guidelines either don’t exist or if they do, they are not easily or widely accessible. This lack of knowledge reuse directly impacts the speed of building new functionalities and the quality of new solutions by limiting the need for extensive testing.

Consequences of a lack of knowledge reuse

When developers don’t share knowledge you risk duplication of effort on solved engineering problems.

The second case where a lack of knowledge reuse can bite is when someone needs to learn something new. They may do this by talking to others, or reading the documentation to develop a design proposal that meets business requirements..

Although the first scenario is bad, the second scenario seems much worse. You have a clearly wasteful duplication of effort that is holding back delivery and impacting quality.

Inner loop and outer loop development 

As engineering leaders, we want developers focused on the most impactful tasks, not searching for information and working on solved problems. Consulting firm McKinsey breaks software development tasks into inner loop and outer loop:

• Inner loop consists of activities directly connected to the implementation required.
• Outer loop consists of the necessary activities to send the code to production.

Applying this to a software context, these can be expanded to include:

Inner loop consists of any work that a developer does that is strictly focused on delivering value to the customer through their knowledge of technology, the tools available to apply such knowledge, and the business they operate in.

Outer loop consists of any work that a developer does that is not strictly related to generating value for the customer. This can include having to invest mental effort in building something that already exists, or searching for recommendations in the documentation that could be more efficiently served.

While many outer loop activities are important to keep engineers connected and aligned, platform engineering aims to free up developers to focus on tasks that best fit their abilities by minimizing any superfluous outer loop activities.

How can we keep developers in the inner loop?

These scenarios can be avoided by focusing on materializing knowledge for easily available reuse.

By simplifying and productizing certain outer loop tasks as part of an internal developer platform, it’s possible to boost delivery velocity and reduce the cognitive load on the team.

For example:

1. Build templates – for already designed services and different types of requirements.
2. Code templates – such as a standard listener for a specific queue.
3. Database configurations – pre-built and available according to certain common usage scenarios.
4. Specific library configurations.
5. Cloud resources – infrastructure options that are already provisioned following the company's financial and security recommendations.

This list of platform components can grow to cover more edge cases over time. There will be situations where certain standards only apply to a specific team. Or knowledge that is valid for several teams working on the same product.

The platform team should work to understand the developer population and treat them clients with specific needs that can be solved and productized for wider reuse.

To build or buy a developer platform?

The decision to build or buy a developer platform hinges on many of the same factors as any technology. 

When you build the solution in-house, you control everything, which can be a competitive advantage. At the same time, the cost increases significantly because you will need investments, and a team to fix the problems that could appear. The generation of value is no longer immediate, and the bet is that the return will come in the longer term.

When the decision goes towards buying, the expectation is that the value delivery is accelerated, which needs to be closely monitored. A critical analysis of the product being purchased, the supplier, at the very least a Proof of Concept (POC), and a refined feedback loop are necessary to understand if expectations can be met.

I suggest seeking a middle ground. Start with a product that delivers the essential concepts for a developer platform, but is extensible enough to be customized by your own platform team, such as Zup’s StackSpot enterprise developer platform.

Final thoughts

The challenge of knowledge reuse within engineering teams is a significant hurdle. Embracing knowledge reuse can accelerate the development process and improve the quality of solutions. That’s why efforts should be made to keep developers focused on delivering value to customers, and minimizing the time spent on non-value-added activities.

A developer platform can be a great first step towards centralizing knowledge and common development patterns to free up developers to do what they do best.

Learn more about how StackSpot can help developer teams focus on what matters by centralizing knowledge, tech patterns, templates, and plugins.