Borrowing from several antecedent disciplines, developer experience is beginning to emerge as a distinct practice of its own. It borrows heavily from more general user experience techniques, as well as from developer relations and community management approaches. One of the pieces that I’ve felt was lacking in this space was a coherent framework – maturity model if you like – of how to approach the practice of developer experience.
Enter Thoughtworks and “Developer Experience as a fitness function for platform teams“. I’ve been a fan of Thoughtworks for a long time – not just their Tech Radar and their support of several tech community groups, and internet freedom events – but for their thought leadership – they challenge norms and aren’t afraid to be skeptical of the latest fad or industry ‘buzzword’. So when Andy Marks and Liauw Fendy were going to put on a session around Developer Experience I knew it would be worth a 3 hour round trip commute.
What is Developer Experience?
The session started off by defining Developer Experience – summarised as “user experience when the users are developers“, or more verbosely – building on the meaning of user experience itself;
“peoples perceptions and responses resulting from the use or anticipated use of a product, system or service”
We then explored what it means when we say ‘platform’ – and that most people have a very narrow view of what a platform is, but really, each platform has several components – it’s not just an API;
- client libraries
- test stubs
- documenation
- source code
- tutorials
- FAQ
- quick start guide
- community
- evangelists
- support processes
- deploy pipeline
- update and release strategy
The term “fitness function” itself is taken from Thoughtworks’ book ‘Building Evolutionary Architectures‘ – and is
“an objective integrity assessment of some architectural characteristics”
which can be used for continuous improvement purposes.
The discussion then turned to what is meant by good Developer Experience – both form and function. Using Aaron Waker’s Hierarchy of User Needs, we explored what it means for a Developer Experience to be
- functional
- reliable
- usable
- pleasurable
In the absence of a more formal maturity model, the hierarchy of user needs serves as a good starting point for understanding an organisation’s current level of Developer Experience and a way to prioritise improvement.
Drivers for investing in Developer Experience
We also discussed the drivers for investing in Developer Experience – which were generally very practical and focussed on reducing the cost of support;
- If you build it, they won’t necessarily come; there are lots of development platforms available these days. If the development experience is poor then developers can easily switch to a different platform; developer experience is vital as an attractor for your platform, particularly if it’s commercially oriented.
- If you don’t provide a strong developer experience, then developers who use your platform which build their own processes and approaches – essentially a shadow developer experience, which you can’t control. A robust developer experience gives you more control over the community.
- Strong developer experience ‘frees up’ the platform team to be able to build more functionality and features, because support load reduces – developers are better able to ‘help themselves’, reducing interaction time on the platform team.
- If you have strong developer experience, you will have more productive developers – able to build stronger, more featureful applications on top of your platform.
Measuring your Developer Experience
This was one of the most useful parts of the session – how to measure your Developer Experience, because if you can measure something, you can manage something.
- Frequency of errors – what errors do your users get, and how frequent are they?
- Documentation – which docs are used the most? Focus your effort here.
- Repos – Issues created, PRs, repo stars and repo forks
- Deployment processes – speed and ease of deployment, and continuous integration and continuous deployment processes.
- Community – in bound requests and Net Promoter Score values.
When questioned about whether there was ‘one metric to rule them all’, the presenters offered;
“Mean time to first hello world”
which I found really interesting on several levels – getting something working quickly is more important now that teams have adopted Agile and minimum viable product approaches. On a psychological level, it also makes sense because if you can build something quickly, you’re going to be more motivated to expand your development.
I found all of these very informative for building a Developer Experience Metrics framework – even a cursory glance around the web shows that there isn’t a lot out there in this space – certainly not an industry-adopted ‘standard’ found in more established disciplines such as Service Desk Management or Incident Resolution.
Developer Experience lifecycle
Another key concept that was used to explain how maturity could be increased in Developer Experience was that of a ‘lifecycle’;
- Find – Is there a platform? Here the developer is seeking a platform for their needs. How is your platform found? What are developer first impressions?
- Learn – How do developers learn to use your platform? How good are the docs? The tutorials?
- Build – How do your developers build? What do they get blocked on? What are their key obstacles or pain points?
- Run – How do your developers operate the software? How quickly does it run?
- Grow – How do you grow the number of consumers on your platform?
Together these stages form a ‘funnel’ – like a sales or marketing funnel, but with the aim of moving developers from ‘interested’ in your platform to active builders, and hopefully, advocates.
Parting thoughts
This was an excellent session – and the practice of Developer Experience is here to stay.