Are you a manager desperate to cover up their own lack of productivity and general uselessness by implementing a system that will allow you to constantly lament your underlings apparent lack of productivity? Well if you are managing Software Engineers, I have some really good news to share with you today. Some people over at Microsoft Research, Github and the University of Victoria have devised the answer to all of your problems. And all it took to get there was a global pandemic and resulting lock down to allow them to refine this miraculous idea and unleash it upon all of us unwashed non-productive engineers!
Can I get a Hallelujah brother? How about an Amen? Because this is fucking spectacular news and it needs to be spread far and wide. Now I can already hear the more corporate inclined among you all asking, “What is this system? I want to implement this right goddamn now!” Well you are in luck because rather than offering to sell you this information, I’m feeling particularly generous today so I’m just going to give it to you. For free. No strings attached.
Well… except you have to listen to me tell you what a fucking brain dead idea this is and rip it a new asshole six ways to Sunday. Are you good with that? Awesome. Now that the terms of our exchange have been set and you have implicitly accepted them by continuing to read, please know that I am also forcing you into binding arbitration with me in the event that you ever have a conflict with me in the past, present or future that you would like to see resolved. Thanks Disney!
Sorry that was something unrelated that I just needed to get off my chest. It’s not worth a rant on it’s own, at least not here because its not strictly tech related, but Disney is a shitty company and you should absolutely stop doing business with them forever. Fuck them and fuck their lawyers.
Okay back to the actual rant, now that you accepted the terms of our arrangement. This miracle of management is called SPACE. Because hell yeah. Everybody loves Space, right? Especially those astronauts who are stuck there because Boeing couldn’t even engineer their way out of a wet paper bag lately.
So what is SPACE? Well long story short its some sort of relatively “new” way to measure developer productivity by attempting to combine not-so-well defined satisfaction metrics and the stat based metrics of the past that have been debunked as useless so many times over, it boggles the mind how anybody with a functioning brain could think this was a good idea. But hey it was a pandemic and we were all going crazy in lock down (unless you were going crazy by pretending COVID wasn’t real, but I digress) and people needed something to do. So why not invent a misguided system for measuring developer productivity? Right?
Well until earlier this week I had no idea this abomination even existed and I likely would’ve remained blissfully unaware of its existence had the misguided executives at my new employer not decided to un-ironically announce that they were going to begin implementing this. Let me assure you, they were completely shocked when the Teams chat and QA and session exploded with skepticism and sarcasm. They really didn’t see the negative reaction coming.
Okay lets start with the basics. SPACE is some management acronym. You know they love that shit like hamsters love pellets and poop, so thats fine, let them have it. In the event that you don’t feel like reading the article on SPACE that I linked above, here is a easier to digest YouTube video which “explains” it. It is 25 minutes long and if you haven’t contemplated suicide by the time you are done watching it, you may not be the target audience for this little ole rant of mine.
Our executives shared a chart that was extremely similar to the sample one Microsoft provides in the video, so much so that I’m not going to bother getting into the differences which basically amount to rearranging chairs on the deck of the Titanic. With that out of the way, let’s attack each letter individually, shall we?
-
S is for Satisfaction & Well-being
This column is actual pretty easy to explain but its also one of silliest ones. That’s because all of these metrics are relative. What makes me happy as a developer, may not make Bob, Susan or Shantell happy. All of us have different preferences and that’s okay. But while I may actually think that Visual Studio on Windows is a raging dumpster fire of the highest order that infuriates me on a daily basis, Susan might think its the greatest thing ever. Bob might even like it so much that he decides to add Resharper into the mix, because having your IDE run fast and efficient is something that the cool kids aren’t interested in. Of course then you got Shantell who’s got a decked out eMacs setup with VIM keybindings over there laughing at all of us n00bs.
The real purpose of this column isn’t about tooling and pipelines, its basically to capture whether or not you are likely to quit. If you think the tooling and the processes suck and you value your craft at all, you are probably going to quit at some point. When developers quit, managers eat shit and they mostly want to keep that from happening. Well, the lower level ones anyway. The higher level ones probably don’t even realize we are actual people, but again I digress.
The point of this is that every developer works differently and generally uses tools they picked themselves to facilitate their custom workflow. And that’s okay… unless you are being measured by SPACE because then well - we apparently need to normalize all the things so that we can achieve some minimum level of aggregate satisfaction. That’s underlying theme behind all of these metrics: Resistance is futile, individuality is obsolete.
-
P is for Performance
This column is odd. While I won’t argue that a heavy and long running code review process is a definite problem, sometimes that’s just an unavoidable consequence of the kind of work we are doing. So I’m a bit torn on that as its level of applicability is going to vary wildly based on the problem space and the engineering standards that are in place. For the most part at my current employer, the code review process is fine. Our team is rather large though so I get at least 50 to 70 emails a day from Github which I mostly just ignore and delete. Yes I do code reviews, but the sheer volume is impossible to tackle so sometimes I just need to ignore the shit so I can get some actual work done.
Now as for Story Points, that’s a fucking hoot and a half. Anybody who thinks that story points are translatable to anything other Schrute Bucks and Stanley Nickels is an absolute buffoon. In fact, my current team doesn’t even bother with them. So I guess our number is always going to be zero… or perhaps we’ll start arguing over how many unicorn farts it takes to implement that latest customer request. Awesome. That is going to be a definite improvement… not.
In fact the only things in this column that aren’t mostly bullshit are the “Customer satisfaction” and “Reliability” metrics. These are real and they are measurements that we should aspire to always be improving our performance around… at least within reason. The idea that planned or scheduled downtime isn’t allowed is silly. Also sometimes shit hits the fan. Nevertheless, I like those things because I think they actually matter.
-
A is for Activity
This column is where the real stupidity comes out to play. I would argue that every single fucking thing in this column is bullshit and absolutely not worth measuring. Again Story Points comes up which is utter lunacy. They are useless metrics that form the backbone of the story of how MBAs invented SCRUM so they could co-opt and murder Agile while running around like Hannibal Lector and wearing its stolen face as a mask. Lovely visual, eh?
Number of code reviews is dumb because that’s an easily gamed metric. I can submit PRs more or less often at will. So what? Number of commits is beyond idiotic because just like the number of code reviews, I can commit more or less often depending on how I want to work and how my brain feels about the work I am doing. To me a code commit is a unit of work that I want to preserve. I suspect most developers probably treat commits in a similar fashion. Once I get some piece of the puzzle written or debugged and it meets some minimum quality standard, I will tend to commit the work. That way if my next stage of work goes awry and I need to go back to this point, I can do so very easily. It is also a way for me to backup my work in case something goes terribly wrong on my system. Due to that belief, it is a rare thing for me to commit and not also push my work up to the remote. Your mileage may of course vary. Some people like to commit and then keep amending to that commit and once it’s “done” that’s when they push it up. Which is perfectly fine. That’s kind of the point though. This metric doesn’t account or allow for any of that.
Oh so before we get to my favorite one, lets address “Frequency of Deployments”. This is dumb. This is a very relative metric and driven very much by the kind of thing you are working on and the stage of development you are in. Sometimes its appropriate to deploy every day. Sometimes its not appropriate to deploy for months. Sometimes it takes weeks just to figure out what the fuck you need to even do to begin tackling a problem. Not all of this work involves sitting at the keyboard and randomly mashing buttons like a rabid monkey would. Sometimes we need time to think and discuss. Not every unit of work is deployable.
Finally, we have “Lines of Code”. You know, what makes the inclusion of this metric on this chart especially egregious is that most of the authors are actually employed by Microsoft (this includes the Github people, which is owned by Microsoft). That’s because the core disagreement with using lines of code as a metric actually came out of a conflict that arose between Microsoft and IBM regarding how Microsoft would be paid for their services:
In IBM there’s a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand lines of code. How big a project is it? Oh, it’s sort of a 10K-LOC project. This is a 20K-LOCer. And this is 50K-LOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS/2, how much they did. How many K-LOCs did you do? And we kept trying to convince them – hey, if we have – a developer’s got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he’s made something smaller and faster, less K-LOC. K-LOCs, K-LOCs, that’s the methodology. Ugh! Anyway, that always makes my back just crinkle up at the thought of the whole thing.
Even Steve Ballmer, who used to be the CEO of Microsoft, knows this is a terrible idea. It makes no sense. Never has, never will. The only thing a lines of code measurement is good for is to get a feel for the relative size of a code base, but even that is only useful in the loosest sense as directly comparing one thing to the next with this metric isn’t likely to yield useful results.
But hey it’s not just Steve Ballmer, Bill Atkinson at Apple had problems with this in 1982 as well:
When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied.
Those who do not know history are doomed to repeat it. This column more than any other reveals the absolute lack of respect for the history of this profession and the collective learnings that should serve as the shared foundation upon which we can build a better tomorrow. Instead what this system and its proponents are choosing to do is foist upon us a system that totally disregards these learnings and opts instead to redefine perception by denying observable reality.
-
C is for Communication & Collaboration
This column is basically a mess of relative things, most of which don’t actually mean anything. For starters “PR merge times” is the same as “Code review velocity”. Everything else is basically impossible to measure. Of course, maybe somebody will email me and inform me of some previously unknown way to quantify the “Quality of meetings” (hint: most of them are a total waste of developer time), measure the quality and thoughtfulness of Code Reviews (probably directly translatable to something idiotic like number of comments made) or how you measure the level of knowledge sharing.
Maybe somebody will also email me the secret that makes Cold Fusion a reality or how to turn Lead into Gold. That would certainly turn my whole modus-operandi on it’s head, now wouldn’t it?
-
E is for Efficiency & Flow
This column is basically just filler. Again they list “Code Review timing” multiple times which has already been listed under various aliases within various columns and it’s mostly just bullshit. Lack of interruptions is a nice thing to measure, but again, its hard to quantify this in a way that is universally applicable across an organization. If shit hits the fan somewhere and developer talent is needed to get to the bottom of it, interrupt away (I say that knowing that I hate it when it happens to me, but its just the price we pay for building broken shit I guess). If you are interrupting me because you are feeling lonely or scheduling pointless meetings with product to groom tickets that they don’t even remember putting on the board then please don’t waste my fucking time.
Clearly I have better things to do, like research SPACE and craft an epic rant on the topic. Truth be told, this is absolutely work related and my level of concern is at such a point that I have no problem getting paid to write this rant. Mostly because this is allowing me to get my thoughts in order so that in the event upper management wisely decides to reconsider this decision and host an open forum of some sort, I’ll show up with something more substantial than rage and spittle.
As for the rest of the column, it bollocks. The only interesting bit here is the “Productivity perception” which I suspect revolves more around management’s perception of your productivity rather than your own. God forbid anybody ask me what my perception of that is. My mood is so fatalistic nowadays that my urge to not rock the boat and flutter my way into burnout and whatever my next career is will likely be superseded by my burning rage, the likes of which a thousand dying stars going super nova at the same time couldn’t match, and I will simply tell management that our software is over-engineered, our product people are largely detached, our product base is becoming increasingly disjointed and our tech debt is nearly unmanageable (unless you consider ignoring it and hoping it will go away a viable management technique).
That would be bad. But I digress.
So what am I going to do? Well if actually read all of my rant then you already know what I’m going to do. Mostly shut up and lay low because people with mouths as big as mine don’t tend to do well in systems like these. I registered my knee-jerk objections (sans poor language choices) in the chat of the initial meeting where this was presented and I am committed to doing so again if they choose to host a follow up meeting, but I doubt that’s going to happen.
I wish I could end this discussion with some happy sentiments, but alas I cannot. The only thing that makes me happy here is knowing that ultimately I will be able to devote a little extra brain power to gaming this system and preserve my existence and paycheck for awhile longer. Smaller commits, smaller pull requests, pointless PR comments (even on PRs that actually don’t require one, sorry co-workers). That should about do it.
How droll.