Developer Experience as a fitness function for platform teams

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.

Image: Ember Code by Kovah on Flickr, CC-BY

Software Freedom Day Melbourne 2011 focusses on community building

This year’s Melbourne-based Software Freedom Day event took a low-key approach, in stark contrast to last year’s award-winning affair. Hosted by Linux Users Victoria at The Hub in Docklands, the day kicked off with a BBQ (with opensauce – props to Lev Lafayette for a very witty pun). Unfortunately due to a power failure at Southern Cross Station, my V/line train from Geelong was delayed by over an hour – meaning I missed the BBQ.

Ben Sturmfels opened proceedings by explaining the need for software freedom, and why it is so important for us to value freedom – not only in software and computing but in everything we do. A key topic of the discussion which ensued was resolving the tension between hardline ‘fanatics’ in the community – those who baulk from using any form of distribution for example which contains elements of proprietary code – as Ubuntu and Debian do – and those who take a more liberal and pragmatic approach to using free and open source software.

The afternoon saw two groups of three workshops held – and I chose to attend that run by Alex Garber (@clockworkpc) on promoting FOSS and how it can be better marketed. It was clear that people were drawn to free and open source software via a variety of channels. Some arrive from a philosophical or idealistic desire to have more freedom over how they use their computer. Others have pragmatic reasons – such as lack of financial resources – for using FOSS solutions. Additionally, as pointed out by two-term LUV President, Lev Lafayette, FOSS alternatives can offer productivity and processing advantages over their proprietary cousins. This represents a distinct advantage in high performance applications such as those used in science and engineering. Participants in the discussion recounted some of their introductory experiences to Linux and open source software, with many indicating that they took a ‘softly-softly’ approach – often dual booting into Windows and Linux before making the move to a Linux only platform. The ability to use key software packages under Linux operating systems remains a key barrier to adoption; although applications such as EndNote have FOSS alternatives – LaTeX – the data formats they use are often closed or proprietary, thus making data interchange difficult.

I then facilitated a session on building and sustaining FOSS communities. Many of the themes were not new, but what was so encouraging and enlightening about discussions were the depth of passion people felt for the groups of which they were a part (including Andy Gelme – President of Melbourne Community Connected Hackerspaces and Ben Sturmfels, Convenor of the Melbourne Free Software Group).

We covered a lot of ground. Discussions started around community standards – standards of dress, behaviour, deportment andw hygiene are seen as important – both to set expectations and avoid ‘putting off’ potential new members of the community. The need for leadership, management and facilitation skills for those in senior roles in free software groups was discussed, without reaching consensus on whether it would be worthwhile to actually invest money in providing training for key members. This naturally led into a thread on the need for mentoring within the community – and establishing both formal and informal channels for knowledge sharing to continuously nurture a pool of talent ready to take on leadership roles. Diversity, as ever, was a hot topic – and it was encouraging to have three women (including myself) in the group of a dozen or so. The general feeling in the room was that there is no silver bullet to solving issues of diversity and inclusion – other than that as a community we have to critically examine our practises to ensure we are not being unwittingly exclusive in our behaviours.

The difficulties of establishing FOSS communities in regional areas – without a large critical mass of interested people – were also touched on. Here, the group suggested having regular groups with a broader focus to ensure sustainability and sufficient interest – such as a programming group rather than one focussing on a specific language or technology.

We also did some ‘blue sky’ work, and envisioned what we would like free and open source software groups to evolve into over the next few years. To summarise, the desire was to be recognised as a legitimate and trusted source of advice both for open hardware and software solutions. In particular, the desire to be viewed by industry and business as a respectable, reputable option viz a viz proprietary options, was highlighted. The need to do more ‘reach out’ type work with other community groups focussing on social equity and justice was also a strong theme of the session.

The threads from the discussion were mapped using FreeMind and are available below.

NOTE: Unlike the rest of the material in this blog, this post is released under the CC-BY license as below.

Creative Commons License Software Freedom Day Melbourne 2011 FOSS Community Building by Kathy Reid is licensed under a Creative Commons Attribution 3.0 Unported License. Based on a work at