author: @sleepyfox
title: Time to decelerate
date: 30 October 2020
preamble: Sometimes going ever faster is not the answer
Imagine you're an alien from another world, a crustacean-like species from an ocean world orbiting Epsilon Eridani, and you're researching Earth civilisation and culture. You're interested in the whole earthling obsession with quality and food, Michelin stars and celebrity chefs. On your world food is fuel, you eat rocks. Rocks provided by your world government as a service to citizens. There are no restaurants.
So you set out to try and understand what food quality is all about. You study camera footage of people eating. You study menus and customer bills. Your drones creep into restaurants at night and analyse tableware, decor and interior design.
After years of collecting data from thousands of restaurants around the world you publish a book on your findings, for the delight and edification of your fellow aliens. You prove a correlation with the prestigious Michelin stars, and several interesting factors:
- The percentage of wait staff wearing tuxedos
- The size of the bill
- The weight of silverware on the table
Satisfied with your work, and having many of your colleagues pat you on the carapace for your good work, you return to the home-world for a well earned vacation before studying a new alien culture.
Now imagine your surprise when your fellow Eridanians decide that they will open restaurants, and take your work as a handbook for success. You are shocked! Surely they read the appendix in your work talking about experimental methods and stating that (of course) your analysis isn't a causal model, and that correlation doesn't prove, or even imply, causation.
But this is exactly what is happening with Accelerate: 'The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organisations', the book published in 2018 and so beloved by technology managers and executives around the world.
And yet, here we are, in 2020, with people doing the mental equivalent of finding rocks around burnt-out campfires, and therefore thinking that they can make fire by banging the rocks together. Of course what is worse is that sometimes people will succeed (because pyrites) and this further fuels the BangRocks movement.
The problem is that managers, upon reading the book, see it not as interesting research that can spur their own experiments, but as a prescription to producing a 'High Performing Technology Organisation', despite the authors proclamation on pages 136-140 that correlation does not equal causation, and that they didn't do any causal analysis, because "we did not have the data necessary for this kind of work" (bottom of page 139).
I suspect that there is a correlation between cadence of release and economic success, partially because you have a lot of people in large companies, and therefore you need to find a way of having all of those people release things because otherwise you'll be less likely to make a profit, and partially because if there's something stopping you releasing work, it's probably also stopping you doing the things that will make your customers happy and you making more money. Although it's difficult to actually tell from the book, because they haven't released the data, nor published their workings, and the sample set is biased (DevOps report self-assessed survey results).
But what we have here is managers figuratively putting more cutlery on the table, dressing their wait staff like penguins and raising prices in the hope that their restaurant will be more successful. And then wondering why their BangRocks transformation hasn't yielded the results that seemed to be promised.
If I were to ask 'What is the ideal size for a method?', you might answer something like: 'small enough to encapsulate a meaningful chunk of functionality, without being so small as to be obtuse or obscuring the relationship between the component parts'. If I were to ask 'What is the ideal size for a PR?', you would probably say much the same thing. But tools like CodeClimate would say 'the smaller the better'. What, even just a single line? 'Yes', says CodeClimate and other tools, because they can only measure lines of code, they cannot measure whether an abstraction is meaningful or meaningless. Similarly Accelerate seems to imply that the faster you release, the more value you create, without ever actually measuring the value. Yes, it is likely that if you can't release quickly, you are probably not realising as much value as you could by releasing more quickly (because Cost of Delay), but equally well if you're incessantly releasing small things which have negligible value then your earned value per unit time isn't optimal either.
This is leaving aside the fact that for most organisations, releasing isn't the biggest obstacle to success anymore (though of course there are always laggards), instead it is producing what the customer actually needs and will pay for instead of more useless features, and writing low-TCO code rather than buggy unmaintainable code that you'll only have to pay to refactor later. Many times. Write the right code and write the code right.
As an industry we should be focusing on fulfilling customers' needs, and producing as little code as possible in order to do,as well crafted as we can. Instead works like Accelerate are motivating management to produce more, more quickly, without actually understanding quality or needs.
Understatement of the year: "(though of course there are always laggards)"
Luv luv luv the "BangRocks" analogy as well. Thank you for that. I totally intend to use it.
Have anything similar on the topic of "closing the loop" like finding out if the customer is actually using the thing that just got delivered and do they keep using it? Would live to have a memorable way to get the message across that "delivery" is only a first step.