Submit to SREEmea

[pburkholder]

As SREs, we're regularly called upon to advocate for a particular investment or course of action. To bolster a case, it can help to call upon the relevant experience of our community, or from behavioral science, particularly when that has coalesced into an eponymous law such as Brook's Law, Gall's Law, Whong's Law, or Javon's Paradox.

BUT: Sometimes it’s hard to remember which law (or razor or effect) is which. What if there was a way to recall these laws and use them in context? In this conceptual talk, I'll cover the laws I've found most useful when consulting on socio-technical issues, provide examples of how they apply to our work, and, most importantly, share some mnemonic tips to call up the relevant law at a moment's notice. I'll close the talk with an interactive quiz, so folks feel confident and ready to apply these concepts to their work.

-- LONGER DESCRIPTION --

I've presented a version of this talk at an internal developer conference, and it's been gratifying to see the key points come up in our Slack as in the following:

Heather: why is it that no matter how realistic I try to be with my time estimates, everything is always at least double the time I think it is

James: Hofstadter's law!

While that's a fairly trivial example, we can ignore these laws and be tripped up by them, or we can leverage them to our advantage. One situation I see commonly in my work is an organization's attempt to cobble together disparate technologies into a "common platform", generally attempting to defy Gall's Law:

Gall's Law: Every complex system that works has evolved from a simple system that works

and by specifying a lot of complexity up front, they are doomed to fail. A better approach is to build the simplest platform that meets the needs of one customer, on-board them, and then iterate to add features and customers. Bringing up this law has helped guide our partners to simpler solutions, and it's helped to have these laws at the ready.

The point of this talk is to equip senior SREs with a toolkit of eponymous laws that they can call up as needed and apply to their work. For each law, I'll provide:

• Background and context for the law
• Real-world examples (when I have them)
• A mnemonic rule for recall

For Gall's Law, John Gall is best known for his 1975 book General Systemantics: an essay on how systems work, and especially how they fail. He originally formulated his observation as:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

That's too long, so I prefer the shorter version above. As for my mnemonic rule:

A worm's gut is simple because it eats constantly, however, we've evolved a GALL bladder for our more complex needs and big meals.

The outline below lists the key laws I'll cover, and we'll close with a 2 or 3 minute pop quiz as a call & response. For example:

• Slide: This proposed architecture is too complex. We'll have to start with simpler initial solution, otherwise we'll be attempting to violate _
• Me: Okay - let's fill in the blank on three: one… two… three
• Slide, me and audience: GALL'S LAW

It'll be fun, and we'll learn a lot! Thanks for your consideration.

[pburkholder]

OUTLINE

• Opening anecdote referencing Gall's Law
• Introduction: who I am, how I got here
• Why named laws, or eponymous laws, have become an interest of mine
  • Behavioral Economics & Notions of "cognitive ease" - priming an argument as the application of a named law helps lend credence to your point of view
  • This can be tricky terrain, as it can lead you to "Argument from Authority" when you apply an authority's words, but not their logic, which is a logical fallacy -- but it works for you, then: more power to you.
    • But I have a terrible memory, so I've used simple, if sometimes embarrassing, mnemonic tricks to keep these at hand. And if they work for me, I hope they'll work for you.
• So let's dig into these laws, and for each:
  • Background and context for the law
  • Real-world examples (when I have them)
  • A mnemonic rule for recall

For the meat of the talk, I'll cover the following and their relationships to SRE 

• Dunning-Kruger Effect 
  • explains the tendency of executive/managers to re-org or RIF without understanding the expertise required in particular roles
• Javon's Paradox 
  • why cloud spend etc. never goes down despite continual reduction in per-unit costs
• Conway's Law
  • deploy the Inverse Conway Maneuver: structure teams so they align with the desired architectural characteristics of the system under construction 
• Overton's Window
  • while Google may have pushed the Overton Window of acceptable SRE practice, just because they do something doesn't mean we have to go there
• Brooks Law (which should be well-known already)
  • Late software projects can only be rescued by reducing scope; adding engineers only makes it later
• Gall's Law
  • always start with a simple working system before making it a complex system
• Goodhart's Law
  • you must have this at hand once DORA metrics (or other metrics) are used as a goal instead of a guide. 
• Whong' Law
  • often applies to large organizations, not just government, and could be a logical consequence of Gall's Law.

Final "Quiz" to review all of the laws, and see how we do in recalling or applying these laws.

[pburkholder]

TAKEAWAYS

Audience members will learn about recurring socio-technical phenomena in our work as SREs, and apply these laws to help explain and guide their work, or to advocate for particular course of action.

I hope they'll also take a broader interest in applying behavioral economics and cognitive biases and applying these usefully to their work.