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 2018 Sydney – A little bit of history repeating

This year, 2018 headed back to Sydney, where it hasn’t been held since 2007. This year I skipped quite a few sessions due to having Linux Australia duties and tasks to do, and because the heat and humidity were exhausting. Thankfully, the videos by Next Day Video were released very quickly, so I’m spending “Week 2” of catching up!

On reflection, several themes came through.

  • Volunteers, volunteering and volunteer labour – There are several free software and opensource organisations across the world, and they’re all vying for volunteer contributions. Moreover, the volunteer base itself is ageing; we’re getting older and having children and families and other family responsibilities – we simply don’t have the time to contribute that we once did. At the other end of the demographic curve, younger people don’t have the same passion and ‘fire in the belly’ for free and open source software. In one sense, that’s a product of the success of the free and open source software movement – because it’s been normalised; but on the other hand this leaves us with a gap in the ‘compelling-reasons-to-join-a-free-and-open-source-project’ list. As a concrete example, during the opening of, no less than three organisations – Open Source Initiative, Free Software Foundation, and Code Club Australia – did a shoutout for volunteers. At the same time, Linux Australia – the auspicing body of the conference – had fewer nominations to its board than open vacancies. I want to be clear: The Organisers and Volunteers of did a phenomenal job. They were dedicated, professional, resilient and awe-inspiring. As individuals, and as a conference team, amazing. Systemically though, open source has some major issues to address to avoid burnout, and worse, resentment.
  • Infrastructure-as-code continues to gain maturity – As more and more devices become internet-connected, and we’re managing more and more devices, we need better orchestration. We’re seeing this manifest in container-all-the-things, in MQTT for unified messaging and in our approach to IoT hardware and open hardware. Standards however remain a barrier to interoperability and greater maturity in code-based orchestration, as outlined brilliantly by Kathy Giori.
  • Open source touches many disciplines – the range of Miniconfs available this year sent a strong and undeniable message – free and open source software, hardware and practices are touching many disciplines. Art, genomics, games, galleries, libraries and museums (GLAM) – Linux and open source touch each of these in fundamental ways. Personally, I’m delighted to see this cross-pollination happening in our communities. Together, we do better.

On communities, volunteering and volunteer labour

“A division of labour in free software” – Molly de Blanc, Free Software Foundation

Molly’s talk used the results of different surveys of opensource communities to show visually that labour in free software is gendered, ageist, and that these schisms also apply to what is considered technical and non-technical work. The implications of these findings are that these patterns are repeated without intervening action, such as having quotas on leadership boards. Importantly, anecdotal data shows that we still value technical work over important non-technical work; people still justify their non-technical contributions to an opensource project by emphasising the technical contributions they do make.

This resonated strongly with me; as the leader of an organisation that turns over around $AUD 1 million a year – Linux Australia – there are a number of skills I need to have – budgeting, strategic communications, strategic and operational management – and of course, the ability to be an efficient administrator. None of these are technical skills; yet, as the leader of a technical organisation I am expected to have a strong grasp of technology issues. Even in a non-technical role, you’re not allowed to be non-technical.

“Dealing with Contributor Overload” – Holden Karau

Holden Karau is a core contributor to the Apache Spark project, and this war story and guidance was learned the hard way – when the project became so big that contributors were significantly overloaded. She provided a number of strong pieces of guidance for dealing with contributor overload, including:

  • Developing a contributor pipeline to allow users of the project to become contributors, and in time, core committers
  • Not ‘raising the bar’ for changes and requests because these have very unattractive downsides such as making the contribution pipeline harder and paradoxically increasing the contributor workload by increasing questions and requests for assistance.
  • The power of having clear roadmaps which make it clear what the core project is, and is not going to do, so that people can either start their own project, or plan around it. The Roadmap also helps guide contributions, and show how smaller tasks contribute to larger milestones.
  • Focussing on committer productivity – such as better tools to merge changes, making it easier to review changes, and more tests – can have significant long term dividends. Imagine what a 1% productivity increase would mean across say 10-20 committers? 50 committers? 100 committers?
  • Creating safe spaces to ask questions and contribute without being mocked – people who feel safe to fail are going to commit more.


“Burning Down the Castle” – Daniel Vetter, Intel (previous graphics kernel maintainer)

Daniel’s talk was an eye-opener. As a previous graphics kernel maintainer, Dan has seen a whole range of poor behaviours that contribute to maintainer burn-out, rage-quitting and other unproductive outcomes. His talk advocates for a kinder, gentler approach to maintaining a technically elite community.


“Mirror, mirror on the wall: testing Conway’s Law in open source communities” – Lindsay Holmwood

Lindsay provided an outline of Conway’s law of organisational communication patterns, and the concept of mirroring – the mapping between the organisational structure and the supporting technical structures for communication. Strong mirroring leads to strong ownership – you are led to the actors who own a system. Using an overview of the empirical literature on organisational development and he explained how organisations try to solve the problem of communication – using different structural strategies. But mirroring works poorly in unstable environments – those undergoing radical change and innovation. This has led to the rise of structures like guilds. These theories are then applied to open source to show that shifts away from the ‘core’ of an open source project can indicate a decline in the project itself. This necessitates a need to build a pipeline – again the pipeline – of people moving closer to the core in their contributions.

This talk was intense – but the key takeaway was that the way we design organisational structures has a significant impact on organisational outputs and long term organisation success. This is of particular importance for projects that are scaling up significantly; poor choices during scale up will lead to poor productivity later in the project’s lifecycle.


Orchestrate all the things. With code.

“MQTT as a Unified Message Bus for Infrastructure Services” – Matthew Treinish

This was an excellent talk by Matt Treinish, who outlined the reasons behind the design of MQTT, which was originally designed for sensor telemetry. He goes on to show there are different levels of quality of service for the broker. An excellent introduction to how MQTT can be used as a unified messaging bus – as used in FireHose.


“What does the buyout of @arduino mean for #openhardware?” – Kathy Giori, IoT at Mozilla

I was truly disappointed not to be able to make it to Kathy’s presentation, as it came about partially because of a tweet I’d sent out to #lcapapers in mid-2017 – and which Kathy shouted out to me for. Thank you, and apologies for not being there in person.

Giori provided an overview of the corporate history of Arduino and how it’s now consolidated under one company; lamenting the drawn-out legal process that led to this point.

She continued to outline some of the challenges in licensing for open hardware and how manufacturers are being cheated by lower-quality knock-offs; with those same manufacturers then expecting the original author of open hardware / open software to provide ongoing support. This led to a discussion on the different levels of openness in open hardware, and the pros and cons of each.

Concluding the talk, Kathy provided an overview of the Mozilla Web of Things project, which is attempting to bring some standardisation and streamlining to the very fragmented IoT and open hardware space. There are competing standards, competing platforms, and the piece that I didn’t realise was that this is actually inflating costs for consumers. Because individual companies need to make hubs and supporting infrastructure for “their” range of IoT hardware, this means each endpoint device – light bulb, sensor, thermostat and so on – is quite expensive. Mozilla is seeking to have stronger interoperability in this space by creating the ‘Web of Things’:

“The “Web of Things” (WoT) is the idea of taking the lessons learned from the World Wide Web and applying them to IoT. It’s about creating a decentralized Internet of Things by giving Things URLs on the web to make them linkable and discoverable, and defining a standard data model and APIs to make them interoperable.”

If anyone can drive this, Mozilla can, but my personal feeling is that they’re going to come up against significant corporate interests in doing so – at a time when their own corporate mis-steps (Mr Robot, anyone) have significantly backfired. I live in hope.

Cross-pollination, because together we do better

“The Future of Art” by J Rosenbaum

This was the mind-blowing talk of #lca2018 for me personally. Academic and artist J Rosenbaum took us through their research, which sits at the intersection of machine learning, neural networks and the production of art.

J’s talk started with an overview of machine learning projects, such as Botnik and Janelle Shae, and moved on to underscoring the collaboration between human and machine in generative art.

The future is not man versus machine  – the future of art is man with machine.


“The Knitting Printer” by Sarah Spencer

Again a brilliant intersectional talk by Melbourne-based hobbyist and knitter, Sarah Spencer, in which she provides an introduction to knitting machines, and provides a breakdown of how she reverse engineered a hack to a 32-bit knitting machine to be able to get images from her computer to the knitting machine.

Massive respect, @chixor.


“Wearing access: a story about open collections, a sewing machine and the nation’s secrets” – Bonnie Wildie

Bonnie’s talk, from the OpenGLAM Miniconf, was very much a hidden gem of the conference. She talked about the concept of redaction art, created from files that have been redacted – and remixed. Bonnie even turned the redaction art into a dress, which opened up a conversation on the politics and power of what we wear. Dress and costume become media for subversion. Much awesome.

My talk picks for #lca2018 – 2018 heads to UTS in Sydney – where it hasn’t been since 2007 – which is a very long time in technology.

This year’s line up has swung away from the community-focused content of 2017 Hobart, back to technically-heavier talks. Personally I think this was the right move – without robust technical depth, risks losing its traditional audience of kernel and Linux hackers.

The conference theme of

a little bit of history repeating

plays out in the programme in a couple of ways. First, the conference welcomes back Karen Sandler as a keynote. Karen last keynoted 2012 in Ballarat, in one of the best presentations I’ve ever seen about bodily autonomy, and the impact that software freedoms have not just on technology, but on our personal health. Her talk at 2017 Hobart on ‘Surviving the next 30 years of free software‘ was also thought-provoking – as our community ages, how do we prepare for the death of our community members – and importantly – how to we curate their code legacy? I can’t wait to hear what Karen speaks out in Sydney.


History repeating also plays out in the Miniconfs that we’re seeing this year. The Open Education Miniconf is back after a several-year hiatus, while the stalwart Sysadmin Miniconf is back. Open Hardware is as popular as ever, and has already sold out.

What I love above this year’s Miniconfs is the reach-out and cross-pollination with other disciplines. The Bioinformatics Miniconf is back, after debuting at 2016 (disclosure: I was 2IC of LCA2016). The Art and Tech Miniconf, led by the amazing Kris Howard, is going to be my top pick, because of the cross over with elements such as data visualisation, and even a Knitting Printer.

Main talks

The next generation

  • History can’t repeat unless we have the next generation to repeat it – and David Tulloh’s war-story from volunteering to teach kids to code will provide insights to those running MakerSpaces and HackerSpaces, coding camps and so on about how to engage students in learning code.

Continual learning

Accessibility and inclusiveness

Open source community

Open hardware

Open source making the world a better place