Recently, I did some research and a deep dive on developer productivity – how industry measures it, what inputs and outputs are involved, and how they contribute to business value. During my research, I happened to find a paper published in ACM: a framework called SPACE (you can read the original paper here).

Reminder! This post outlines my own views on this subject after I read a bunch of research papers, and how I can potentially implement it after minimising my unknown unknown. I recommend you read the original paper if you plan to adopt it for your own organisation. None from this post represents my past, current, and future employers.

Before we diving into this SPACE framework, let’s step back and understand what developer productivity really is for us.

What is developer productivity?

To me, as a developer, developer productivity is all about how I feel when I do my job. I sometimes feel productive when I can commit a lot of code and pass the automated test; sometimes I feel productive after having a mentorship session — either as mentor or mentee; sometimes I feel productive after I finally finish reading a book; or sometimes it’s just a matter of publishing this article after spending hours reading a bunch of papers and crystallising my thoughts into a post.

It’s a bit abstract. The common denominator from all of these, is probably an “achievement” after you do your work — for instance, seeing an article being published after you spend hours writing it is an achievement; passing the automated test when you are committing your code is an achievement; acquiring new knowledge and a new way of thinking after you finish reading papers or books is also an achievement.

This is my personal view of productivity, though, and obviously it is far from being scientific.

Now, why does that matter for business?

If we need to tie them back into how they can bring value to the business, developer productivity might mean a myriad of things — for instance, with higher developer productivity, it can result…

  • Well-received features by end users, hence higher products/services adoption;
  • Reduced incidents, hence higher customer satisfaction and retention;
  • Optimised code and architecture, hence lower cloud/operational cost;
  • Lower friction of developer on-boarding, hence lower operation cost;
  • Higher developer satisfaction, hence higher developer retention and lower hiring cost.
  • … and the list carries on …

To achieve all of those, how do we propose KPIs to drive the behaviour? Enter SPACE. Let’s see what it had offered to us on how to understand and measure this subject.

SPACE framework

This framework aims to understand and measure developer productivity based on a constellation of dimensions (metrics), rather than relying solely on a single metric. To understand developer productivity within an organisation, it proposed five dimensions to be considered (you need to select at least three).

  1. [S]atisfaction and well-being
  2. [P]erformance
  3. [A]ctivity
  4. [C]ommunication and collaboration
  5. [E]fficiency and flow

img

Satisfaction and well-being

This dimension talks about how fulfilled developers feel with their work, team, tools, or culture. When it comes to well-being, it talks about how they feel, how happy and healthy they are, and how that may affect their performance.

Possible metrics to capture this dimension include:

  • Developer satisfaction – the degree of satisfaction among employees, and whether they would recommend their team (and potentially their employer) to others.
  • Developer efficacy – whether developers have the tools and resources they need to get their work done.

Performance

It is hard to correlate the business outcomes (or product outcomes) to individual contribution. A developer who produces a large amount of code does not necessarily produce higher quality code, and does not necessarily deliver features that delight customers. It is recommended to use this dimension to measure outcomes, instead of output.

Possible metrics to capture this dimension include:

  • Quality – the health of the service, reduced # of software defects.
  • Impact – feature adoption, customer satisfaction and retention.

Activity

This dimension talks about the number of actions completed in the course of performing work. Developers actually perform complex and diverse activities apart from writing code, such as mentoring junior members or newcomers, code review, and even on-call participation (you build it, you run it!). Because of this, please be aware that it is almost impossible to comprehensively measure and quantify all of the facets of developer activity across the engineering team. That being said, this dimension is helpful to gain insight and tailor improvement plans accordingly.

Possible metrics to capture this dimension include:

  • Code – volume of commits, code reviews, pull requests.
  • Design – volume of design document and specs.
  • Continuous integration and deployment – volume of build, test, release.
  • Operational – volume of software defects, on-call participation, root cause analysis (RCA).

Communication and collaboration

This dimension captures how people and teams communicate and work together. Software development is collaborative and creative work that relies on effective communication and collaboration. Those are, however, tricky to measure, because communication and collaboration are invisible work. They just naturally happen within or between teams.

That said, possible metrics to capture this dimension include:

  • Discoverability of code (software components), documentation, and expertise.
  • Onboarding time and experience for newcomers.
  • Quality of reviews of work contributed by team members.
  • Network metrics that show who is connected to whom and how.

Efficiency and flow

Finally, this dimension talks about the ability to complete work or make progress with minimal interruptions or delays. It is important for developers to allocate a block of time for interrupted focus.

Some possible metrics to capture this dimension include:

  • Interruptions – how frequent, when they occur, and how they impact development work and flow.
  • Number of handoffs across different teams in a process.
  • Perceived ability to stay in flow and complete work.

Strategies to improve developer productivity

Now that we have clearer picture of this subject, we can begin to put some metrics and KPIs in place to guide the team’s behaviour. There are several practices that I can think of to be adopted by the organisation to deliberately improve developer productivity.

Developing a good and supportive engineering culture always starts with the people. Then we can improve the processes/mechanisms in place, and adopt tooling to instrument those processes along the way.

People

  • Build strong team connections
  • Build a good documentation culture
  • Supportive internal feedback loop — for example, utilising 1:1 meetings to get candid forward-looking feedback.
  • … this would be a subject on its own. So, I will stop here.

Process and Tools

Further reading

  1. Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. “The SPACE of Developer Productivity.” ACM, n.d. https://queue.acm.org/detail.cfm?id=3454124.
  2. Murphy-Hill, Emerson, Ciera Jaspan, Caitlin Sadowski, David Shepherd, Michael Phillips, Collin Winter, Andrea Knight, Edward Smith, and Matthew Jorde. “What Predicts Software Developers’ Productivity?” IEEE Transactions on Software Engineering 47, no. 3 (March 1, 2021): 582–94. https://doi.org/10.1109/TSE.2019.2900308.
  3. Storey, Margaret-Anne, Brian Houck, and Thomas Zimmermann. “How Developers and Managers Define and Trade Productivity for Quality.” In Proceedings of the 15th International Conference on Cooperative and Human Aspects of Software Engineering, 26–35. Pittsburgh Pennsylvania: ACM, 2022. https://doi.org/10.1145/3528579.3529177.
  4. Storey, Margaret-Anne, Thomas Zimmermann, Christian Bird, Jacek Czerwonka, Brendan Murphy, and Eirini Kalliamvakou. “Towards a Theory of Software Developer Job Satisfaction and Perceived Productivity.” IEEE Transactions on Software Engineering 47, no. 10 (October 1, 2021): 2125–42. https://doi.org/10.1109/TSE.2019.2944354.