Contributed"> 5 Common Developer Self-Service Challenges (and Solutions) - The New Stack
TNS
VOXPOP
Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
0%
No: TypeScript remains the best language for structuring large enterprise applications.
0%
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
0%
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
0%
I don’t know and I don’t care.
0%
CI/CD / Cloud Services / DevOps / Platform Engineering

5 Common Developer Self-Service Challenges (and Solutions)

Self-service is a way for developers to innovate faster and better, while simultaneously reducing risks for the business. Here's what to do — and what not to do — when setting up an internal development platform (IDP).
Jul 26th, 2023 10:00am by
Featued image for: 5 Common Developer Self-Service Challenges (and Solutions)

How do you enable developer self-service?

That’s a question that more enterprises are seeking to answer as they embrace developer self-service — or platform engineering, as it’s sometimes called — as a means of maximizing the productivity and job satisfaction of their software engineers. Developer self-service represents the next evolutionary step for organizations that have already embraced DevOps since it helps their development teams to make DevOps practices more efficient.

The most obvious solution for enabling developer self-service might seem to be to deploy what’s known as an internal development platform, or IDP. A growing number of IDPs — such as the open source products Backstage and Atlassian Compass, to name two popular examples — are available to help enterprises make a diverse set of technical solutions available to development teams on demand.

IDPs are certainly one component of an effective developer self-service strategy. However, achieving self-service functionality for development teams is more complicated than simply deploying a self-service platform and calling it a day. Businesses also need to address requirements like maintaining their platforms over the long term, updating them to keep up with evolving cloud technologies, managing quality and more. If you don’t think about these challenges ahead of time, you risk deploying an internal developer platform that falls far short of delivering on its maximum potential value.

To prove the point, I’d like to walk through five key challenges that I’ve seen in the field when working with businesses on developer self-service initiatives, along with tips on how to mitigate them.

The What and Why of Developer Self-Service

Before diving into challenges, let’s look at what developer self-service means and what benefits it brings to both developers and businesses.

Put simply, developer self-service is a model wherein software engineers can create the services and environments they need to be productive, without having to ask or wait on the IT department to set up the solutions. Typically, developers do this using an enterprise self-service platform that delivers a variety of ready-made, officially supported solutions — such as a service that allows developers to spin up a Kubernetes cluster quickly and easily, for example, or to create a CI/CD pipeline using approved tools.

When developers can acquire the resources they need quickly and on demand, they can work more efficiently, without having their workflows bottlenecked by bureaucratic processes. That leads to better job satisfaction, not to mention faster innovation for the business.

Developer self-service also helps to mitigate the risks of “shadow IT,” meaning resources that developers spin up without official permission. If a business allows developer self-service and provides ready-made developer solutions, software engineers will no longer have to spin up bespoke services and environments that may not comply with enterprise IT policies — and that are likely to end up unmanaged and unsecured because the IT department doesn’t know they exist.

In addition, the developer self-service model helps businesses to scale up specialized labor that is often in short supply. For example, many businesses have few Kubernetes experts on staff. By having those experts create Kubernetes solutions that developers can then spin up on demand, the business allows the experts to work more efficiently because the experts won’t need to create a bespoke Kubernetes environment for every developer team or need.

Nor do developers who lack a deep understanding of Kubernetes have to spend extensive amounts of their time trying to create an environment. The same logic applies to network engineers, sysadmins and any other type of expert whose knowledge is in high demand across the business.

In short, developer self-service is a way for developers to innovate faster and better, while simultaneously reducing risks for the business.

Developer Self-Service Platform Challenges

Deciding to provide developers with a self-service platform is one thing. Ensuring that the platform delivers the value it is supposed to provide is another, due to the following challenges.

1. Platforms That Don’t Align with Developer Challenges

Probably the most common challenge of creating a good self-service developer solution is the risk that the solution won’t actually address developer pain points.

This can happen because the people who design and build the self-service platform aren’t always developers — or aren’t representative of the enterprise’s development teams as a whole. As a result, they don’t know what developers really need to be more productive.

The best way to mitigate this risk is to treat your self-service platform like a product and assign a product manager (or several) to it. That approach ensures that someone is responsible for assessing exactly what the platform is supposed to do based on what its “customers” — the developers in the organization — need it to do. Otherwise, you risk building solutions that sound interesting but that your development teams don’t really need.

2. Maintaining Quality

Ensuring that your self-service platform meets quality requirements is another common challenge. Low-quality tools and services, compatibility issues between tools and so on can hamper the self-service experience and undercut the value of a self-service platform. If your developers have to spend time fixing the solutions you give them, then the self-service model doesn’t provide the benefits it’s supposed to.

One way to address this challenge is to create automated tests for self-service solutions. For example, you could write an automated test that spins up one of your platform’s solutions, and then evaluates whether it behaves as it’s supposed to. If you run these tests once a week or so, you’ll be able to detect problems early and ensure that your developers aren’t interrupted by platform bugs or other issues.

More broadly, assigning product managers to the self-service problem can help improve quality. Product managers can interface with developers to collect feedback about issues they are experiencing with the platform, and then oversee the mitigation of those shortcomings.

3. Self-Service Platform Maintenance

Even if your developer self-service platform is of high quality, it’s likely to break down over time if no one is assigned to maintain it. The solutions it includes may change over time, leading to support or compatibility problems that need to be addressed through updates. You may also want to add new solutions to the platform, and that requires a maintenance and change-request process.

Here again, having a product manager in place will help to ensure that the self-service platform receives the maintenance it needs. You’ll also ideally have a development team assigned to the platform so it can make changes when required.

4. Cost Concerns

A well-implemented developer self-service platform will save money by allowing developers to operate more efficiently. However, like any other IT resource, the platform itself costs money to build and run, and if you don’t think strategically about how to optimize for costs, you may find that your self-service solutions break your budget.

The antidote here is to have a cost management and optimization strategy for your self-service platform, just as you would for any other solution with significant cost implications for your business. In other words, it’s important to consider the benefits provided as well as the costs for internal developer platform initiatives.

5. Lack of Engagement

Finally, you may run into the challenge that you create a self-service platform and your developers don’t actually use it because they don’t know about it or understand its value. “Build it, and they will come” rarely works in the enterprise.

Avoid this challenge by ensuring that your self-service platform actually solves developer pain points. Advertising the solutions to developers and making them extremely easy to use through excellent documentation and deployment guides will also go far to encourage developers to make the most of the self-service solutions available to them.

Conclusion: Getting More from Developer Self-Service

Deciding to offer your developers solutions on a self-service basis is the first step in taking development workflows to the next level. But just as adopting a CI/CD pipeline doesn’t automatically guarantee all of the benefits that DevOps is supposed to provide, simply building a self-service platform is no guarantee that your developers will enjoy the productivity benefits of a self-service model.

But when you plan for the challenges of developer self-service, you can get ahead of potential weaknesses and create a self-service solution that delivers maximum value to your development teams.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.