Many companies are experiencing challenges with developer experience. Those challenges stem from a myriad of papercut size problems, some of the process elements we started to touch on in a prior post which can be read here:

https://arctir.com/blog/overhead-kills-developer-efficiency

There are also a lot of technical challenges developers face within their day to day workflow. The biggest is often a scattering and isolation of information. Engineers across roles spend a ton of time trying to surface relevant information about code, releases, access, designs, changelogs and ownership. This leads to constant context switching, meetings to work through the isolation and delays when teams with limited access or visibility need information they don't know how to find or can't access.

These annoyances often become blockers. New team members, major outages, security breaches and certain business events like provider or office migrations or reorganization all suffer immensely from this, often grinding to a halt while this gets resolved.

It never really gets resolved though. Wiki's fall out of date, ticket systems become unwieldy to search, github presents both challenges and often layers in access and discoverability challenges. As Gartner notes:

“Developer experience is more than just coding. Several of the technologies seen as having the highest value for developer experience focus on streamlining processes that tend to involve handoffs and interrupt the flow of value delivery.” – Philip Walsh, Sr. Principal, Research at Gartner

This is where an Internal Developer Portal shines. It provides engineering teams a low friction way to consolidate information and views of relevant metadata about software. Put simply it reduces the context switching and information seeking we all suffer from.

Our platform takes solving this a step further by providing API and SDK access to the data inside of the Internal Developer Portal.

This allows developers, security, DevOps/SRE and anyone else who needs access to information inside of the software catalog to get it, in a controlled fashion.

Developers don't have to break flow state, security doesn't have to ask for the right wiki page and the DevOps team isn't trying to find the right point of contact for something nobody has touched in the last few years.

A great IDP or Developer Platform should make getting started and maintaining the platform itself simple. You should be able to get going in 15 or 30 minutes and focus on the bigger problem, rather than toiling with talking to sales or spending months figuring out how to operate Backstage in your environment (hint: our GA is imminent with both on-prem or SaaS options).

We've found this approach to provide the most bang for your buck fast. Higher level functionality like orchestrators, score cards, PaaS are all nice to haves. The first step for most teams should be cleaning up the details and access to the data and metadata within their software estate so they can get more value and accuracy out of higher level functionality when they deploy it.

Imagine tackling a new platform as a service with incomplete or inaccurate information about the software environment. How many spreadsheets do you really want to maintain? How inaccurate will those spreadsheets be by the end of the project?

Compare that with the same scenario but having a developer portal wired in to your environment providing a real world view of the software you are using, even going so far as wiring things up via API.

Significantly faster to get moving and significantly less error prone and overhead intense as you go. The core software catalog functionality in an IDP provides bedrock for a number of process and technical undertakings which improve the overall developer experience, and does so in a low friction way.