The SPACE Framework Explained by Nicole Forsgren | Measure Developer Productivity

Dr. Nicole Forsgren explains the SPACE framework for measuring developer productivity and how to apply and use the SPACE framework. Dr. Forsgren has had a significant impact on the software industry including vast work in developing our best measures/metrics for developer productivity.
You can listen to Nicole's FULL Engineering Room appearance HERE ➡️ open.spotify.c...
-
🗣️ THE ENGINEERING ROOM PODCAST:
Apple - apple.co/43s2e0h
Spotify - spoti.fi/3VqZVIV
Amazon - amzn.to/43nkkRl
Audible - bit.ly/TERaudible
-
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
-
#softwareengineer #developerproductivity

[@georgehelyar]

There's a fundamental problem in "how do I measure the output of software developers". We should just be solving problems for end users. Focus on outcomes, don't measure outputs. Just minimise the overhead in getting changes in front of users, and get feedback from the users. That is agile. I'm being measured on number of commits? Well then I had better take my already small change and split it into tiny changes that don't make sense in isolation to pad my metrics.

[@yrtepgold]

I think that breaking up your commit into smaller chunks makes it easier to track the changes and follow your development process. And it also does pad your stats. There's little downside to many small commits.

[@sunkeehong356]

I tried the SPACE metrics with a team for 1 year. The big failure with it is that, like Dave rightfully points out, it's just a framework and not a list of metrics like DORA was. With SPACE, YOU have to decide what to measure, and that's super hard to get right (as hard as coming up with your own DORA). It can be done, and I used qualitative measures, but I saw others fail. I've seen people measure: "Number of meetings and time between meetings to maximise flow", "Number of posts on the team Slack channel", "Size of PR measured by lines of code changed", "Number of PRs divided by number of releases", etc. All of these failed to measure anything meaningful or insightful. Also, the example metrics (they do come with asterisks) in her article were really bad, including things like Story Points. The genius is in the "What should we measure for each of the 5 areas?", and not just the "Oh these are the 5 areas you should measure".

[@szeredaiakos]

Love Nicole. If anything, she shed light on how incredibly complex and counterintuitive software development can be. But there is always a problem with causality both in Accelerate and DORA. Some of them hit home, but many of them just simply does not apply to a particular context. So yes, reading the stats wrong is always going to be an issue. Take for example, stability and speed. Perfectly stable software does not change. But software which does not change is hardly software. Further, spending months of developer time building up a stable foundation is like the foundation of a house where. Extremely rigid, heavy, capable of supporting anything one can foresee the house could be in the near and far future only to realise after 1 year of development that the house needs to be build 150m south of that foundation and the shape isn't right either. Every single facet of a software can be subject of change. It is a point of instability. What is important, i feel, is the degree of instability, the chances of something somewhere turning out to be incorrect. The bad part is that it can turn out pear shaped for unforeseen reasons, so even that estimate can have a tall error bar. It is extremely hard to measure and predict something with that amount of chaos infused in it. And, yes, I worry about the health of Nicole now. If she does not go mad in the next decade or so we should task her to cure cancer and death. She'll probably manage at that point.

[@FlyFisher-xd6je]

If this is what I think it is, it could be handy. It seems like a way to drill down on specific practices or changes made to improve software delivery performance. If a team isn't doing CI or maybe not doing CI well, they could use SPACE as a guide to choose measures that are specific to CI in order to measure. This way the team can get specific feedback about what they are doing to improve much faster than merely using the DORA metrics. That could be valuable with a little practices.

[@SuperPranx]

Ah, measuring number of commits or PRs… but not lines of code. Now it’s all better. Another BS way of saying who did a better job, but only on the surface. A feature can be done in 3 as well as in 30 commits. Well… I guess I better increase how many commits I do. Wouldn’t want to be last on the commits per hour leaderboard… Useless…

[@7th_CAV_Trooper]

If you can't tell who on your team is kicking ass and who is getting poop on the keyboard without metrics then managing a software team isn't for you.

[@salvatoreshiggerino6810]

If someone asks me if I'm satisfied with a tool I'll lie every single time. Usually someone put a lot of company money and prestige into the shitware or shitcess in question, and I have nothing to gain from making enemies. Will the company lose money and productivity as a result? Sure, but it's too late, you've already made your bed.

[@salvatoreshiggerino6810]

Also don't give me any surveys unless they're verifiably anonymous. I've seen the source code of "anonymous" survey apps, they're really not.

[@josda1000]

Why does this seem like big brother type stuff to me?

[@FlyFisher-xd6je]

Only if it is misused (which could happen). The metrics are meant to be used by teams to improve, not to single out developers or compare teams. If you work somewhere they are doing either of those things you should consider it a red flag.

[@djcrem00]

It is misued already today. Why has there be an increase in Burnout with Trunk based development? Because number of commits and deployments matters. There is a difference between i can deploy multiple times per day, vs i should and have to deploy multiple times per day. Still doesn't measure outcome...

[@FlyFisher-xd6je]

@@djcrem00 CI (trunk based development is needed for CI) isn't an outcome, it's a practice. The reason you would practice CI is to get feedback sooner and more often. If you want to make sure you are building the thing right, and building the right thing, you want to get that feedback through out the delivery pipeline.

[@djcrem00]

@@FlyFisher-xd6je you say getting feedback quick, not producing code fast and deploying micro commits often. So the number of Feedback cycles/time to market matters more. Measuring commits / line of Codes and number of deployments are not measuring it. Of course as an experienced dev you keep the increments small. Maybe i have just seen toxic environments where those metrics become a goal... Godharts law kicks in.

[@MarkUKInsects]

This looks like something that the project manager type will go on a training session for, completely miss the point and make the devs and testers life a misery, and the product and customer will suffer.

[@FlyFisher-xd6je]

How would you recommend measuring improvement in a teams ability to deliver better software faster? I am honestly curious.

[@jasondads9509]

​@@FlyFisher-xd6jedon't give it to anyone outside the team

[@MarkUKInsects]

@@FlyFisher-xd6je This is a difficult topic, and it is not one size fits all. In the best teams I have worked with, the team itself does the measuring and defines success, it's not imposed by some bean counter. Any measurement of success should be measured from the user/customer perspective.

[@Venthe]

Same thing happened with agile, scrum, xp, story points... The list goes on

[@georgehelyar]

​@@FlyFisher-xd6je ask the users, don't measure the team.