SPACE and Developer Productivity

I stumbled upon this post that is outlining an updated way of measuring developer productivity. I recommend everyone to go there and read it.

They called their framework SPACE, which stands for Satisfaction, Performance, Activity, Communication & collaboration and Efficiency & flow. I’d like to add my thoughts to what they are saying.

Satisfaction

The people making the post outline the following points:

• Employee satisfaction. The degree of satisfaction among employees, and whether they would recommend their team to others.
• Developer efficacy. Whether developers have the tools and resources they need to get their work done.
• Burnout. Exhaustion caused by excessive and prolonged workplace stress.

I would like to add that I think satisfied people are happy people and happy people are open minded people. I think open mindedness among your peers in turn creates both satisfaction and flourishing creativity.

I find it important to not mix up satisfaction with giving employees everything they ask for though. My belief is that deep satisfaction is achieved when there are few unnecessary hurdles in your way and you and your team work synchronized and achieve good results for which you are awarded accordingly. Awards when there are no or few achievements results in less satisfaction in my experience.

Performance

These are their points:

• Quality. Reliability, absence of bugs, ongoing service health.
• Impact. Customer satisfaction, customer adoption and retention, feature usage, cost reduction.

This is the main point that developers get paid for. Creating quality and impact. In the short term this could have been the only important point, since this is the meat of why you’re working, in the long run there are still other factors (like Satisfaction and other points in SPACE) that determine long time success.

Activity

These are their points:

• Design and coding. Volume or count of design documents and specs, work items, pull requests, commits, and code reviews.
• Continuous integration and deployment. Count of build, test, deployment/release, and infrastructure utilization.
• Operational activity. Count or volume of incidents/issues and distribution based on their severities, on-call participation, and incident mitigation.

I would consider leaving this point out. When it comes to PRs and commits, that is what feel the most easy to measure for a developer, but it is at the same time quite dangerous if you do.

What you want in the end is the performance, and if you start measuring your productivity based on these other metrics you might create weird incentives for yourself. It is not unlikely that you would start creating more frequent PRs for the same functionality. You would probably also start labeling more things as incidents. I’ve been in places where test coverage was a measurement of success. Now I’m for very high test coverage, but when you blindly state that coverage is the metric you’ll start getting tests that don’t really test, that are just their to increase a coverage percentage. It is much better to try to track the things named under performance in my view.

Communication

These are their points:

• Discoverability of documentation and expertise.
• How quickly work is integrated.
• Quality of reviews of work contributed by team members.
• Network metrics that show who is connected to whom and how.
• Onboarding time for and experience of new members.

To be honest I feel that communication is actually the core of what you do if you work professionally as a developer in a corporation. I think it is a big driver of satisfaction as communication creates ties between people and that’s important for well being. I also think it is absolutely essential for the long term success of any organization. Without communication the organization will become dependent on single individuals which in turn will likely not be very satisfied because they work as small islands independently from on another. Communication is, I would say, the most important point for long term success in an organization.

Efficiency.

These are their points:

• Number of handoffs in a process; number of handoffs across different teams in a process.
• Perceived ability to stay in flow and complete work.
• Interruptions: quantity, timing, how spaced, impact on development work and flow.
• Time measures through a system: total time, value-added time, wait time.

I think they do very well to put this in here. Without this as a measurement of productivity, you would easily boost your productivity by constantly asking other colleagues about everything. This would use their brain power to boost your productivity. The problem is that satisfaction would go down in the team overall, and obviously they wouldn’t get their job done. Now, as I mentioned before I do believe that communication is the heart of what the job as a software developer means in the corporate setting, but one still has to be smart with how and when one does this communication. It is all about balance.