I'm updating this presentation from a 5-minute internal talk to a 15-20 minute talk for technical (or non-technical) audiences. To do:
[ ] Change from .deckset to open-source alternatives, or a visual slide designer
[ ] Create spreadsheet to track key compenents of each law
[ ] #12
[ ] Design closing quiz so it's usefully interactive both online and off
Talk description:
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.
Talk outline - Draft
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
commented
2 months ago
I'm updating this presentation from a 5-minute internal talk to a 15-20 minute talk for technical (or non-technical) audiences. To do:
Talk description:
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:
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:
Talk outline - Draft