Developer Experience Roundtable - Continuous Improvement

This is a summary of our recent Developer Experience (DX) Roundtable #1, hosted by Humanitec’s CEO Kaspar von Grünberg, which focuses on making cloud developers build more productively.

What is developer experience?

You are probably familiar with user experience, the art and practice of creating a product that is a useful, usable, relevant, and pleasant experience for an end-user. Developer experience (DX) is similar, but focuses on the particular needs of developers, and if you’re creating tools for developers, then you should place DX front and foremost. DX can also apply to internal developer teams, and finding ways to help them be more productive and happier. In both cases, bad DX leads to a developer wasting time and looking elsewhere.

As DX is important to consider for any technically minded company, we wanted to start this roundtable series to speak with experts in the field and get their experience and advice on creating good DX.

Guests in this first session were:

• Erik Muttersbach, CTO at forto (formerly FreightHub), a Berlin logistics startup
• Nigel Simpson, Director, Enterprise Tech Strategy at a Fortune 100 company

‍

Communicate

One of the first steps to finding out what developers need and where they face difficulties is to ask them as directly as possible. Both panelists frequently speak with members of development teams to find their common frustrations and problems, and ask how they would fix them.

Nigel proposed you find the recurring or repetitive tasks that developers spend a lot of time on, but bring no benefit or impact to your business, and automate as many as possible. Removing a person from such tasks and replacing them with an automated process so they can focus on more complex and meaningful tasks generally introduces a productivity increase.

Continuously iterate

This blog frequently talks about continuous development, from writing to deploying code, and your DX should follow similar principles. As your team grows, or becomes more global, you need to reassess your tools, practices, and approaches. Adding more developers to solve problems rarely make for a respectively more efficient development process, and if you apply a continuously iterative approach to your team and processes, you can catch potential problems early.

As your business grows into new markets, you need to assess how these affect what you build. Erik mentioned the work forto is putting into expanding aspects of their business into China, a territory that introduces new challenges to their developers, but also the developers they work with.

Choose tools wisely and appropriately

Erik mentioned that in the earlier days of FreightHub, the team used Heroku as their infrastructure because it was easy to get started with, and low cost. While the team now has switched to Kubernetes as they scaled, at the time it was not an appropriate tool for their needs. You can build on many tools, platforms, and previous learnings, pick those that bring you flexibility for the future, but do not feel the need to have to create or use the latest greatest thing. Again, focus on what brings more benefits to your business, and users, and not building for the sake of building.

Measuring impact

Metrics help your team know if changes and improvements are making a meaningful impact on developer and business productivity. Nigel mentioned an initial skepticism with regards to metrics, seeing them as a wall of dashboards that often have no meaning. Not every task a developer undertakes has an explicit outcome that you can track, measure, and assess, and trying to do so can lead you down frustrating paths of tracking meaningless metrics and OKRs. For example, producing more or less code tells you part of the story for a team, little about productivity, or business goals, and even less about resulting developer experience. He changed his mind on metrics when he began to change them into actionable items for a team, for example increasing test coverage is a metric that you can track, and brings a better experience for a development team, and a customer base alike.

Erik mentioned making sure that a team doesn’t “hack” metrics, and that a metric is often a quantitative proxy for something qualitative. For example, if you make a service free, it will increase your net promoter score, but does doing that tell you anything useful? He also mentioned that you should have a long term perspective on new features and their associated metrics/impact. A company like forto does not exist to ship software features, or maintain infrastructure, but to make shipping easier for customers, a customer base that takes time to adapt to change.

Avoid technical debt as soon as possible

Switching tools or practices often highlight problems in your previous methods and tools. Nigel mentioned that when teams started using Snyk, it highlighted legacy security issues that needed fixing. Automating these sorts of tasks as early as possible helps identify them sooner, and helps individual team members take responsibility for them as they find them, instead of waiting for a specific team to handle it, or for an activity such as an audit.

If you’re using open source projects to build your products, then select projects that have an active community and that are well maintained, so as not to have a detrimental effect on your own technical debt. If you have the resources to do so, it is worth considering supporting an open-source project you rely on with code contributions or other resources.

Next frontier

The closing question asked the panelists, what’s currently happening in the developer productivity space that they think will bring the next great leap forward in productivity.

Nigel mentioned a recent attempt to understand the skill and knowledge experts present in a team, a task that many of us have probably attempted or been a part of, but generally remain unused, and not useful. Often this is because companies tend to create or use new tools that require people to add to, and keep up to date. However, the information required to make a system useful is already present in their pre-existing social graph. Nigel sees an increasing need for a tool for large distributed teams that dynamically gathers relevant expertise knowledge from platforms such as LinkedIn or GitHub, and helps teammates and managers know whom they can go to for help with specific questions.

Erik is interested to see more tools that allow a company like forto to abstract the development process even further to an even higher level than now. He doesn’t want his team to have to think about the “solved problems” of infrastructure and managing services, but on innovation for their problem space.