Profile picture
Michael D. Hill @GeePawHill
, 29 tweets, 4 min read Read on Twitter
always small, always better, always wrong.
this is the mantra for anyone who seeks change in virtually any genuinely complex environment.
i've written a lot about small and better, but not so much about wrong, which is what i want to take up today, but first, a little refresher.
the complex systems i deal with professionally all fall under the simple problem statement: "make software for money".
those systems include lots of different aspects and layers. two of these, at first blush vastly different, are "changing code" and "changing organizations". my contention is that they actually require the same approach: always small, always better, always wrong.
always small is the discipline of focusing nearly all of our attention on the smallest possible change whose outcome we think we can detect.
in changing code, this manifests in a bunch of ways associated with the modern synthesis. TDD tests, for instance, work by asserting very small missing behaviors in our code followed by the changes that make those small assertions become true.
continuous integration works by taking such small steps and continuously "stuttering" them into the larger code base. story slicing works by taking each story and splitting its intended value into tiny 1- and 2-day chunks.
the deep basis for "always small" is the recognition that mental scope -- the number of things we have to think about at one time -- is the biggest generic indicator we have for whether that thinking will be successful.
always better is the discipline of pathfinding locally, taking those small steps and making judgments about them based absolutely on whether they represent actual improvement over what we had before we took them.
it is at its heart the attitude that every change we make must justify itself immediately after the fact to earn any real trust from us.
in changing organizations, for instance, the skilled leader's basic obsession is on creating sticky change. the easiest way to think of this: "will they keep doing this when i look the other way?"
the not tremendously shocking truth: they will keep doing this if they think it is helping them right now.
am i saying that short-term gratification is the way forward?


the actual variation in human's ability to hold on to a negative or even neutral behavior is of course a bell curve with a modal. different people live on different locations, to be sure.
but the modal of that curve? "does this feel better when i do it?" don't get all bitter and cynical. after all, it's just a tall bump on a curve. and more importantly, "feel better" is itself a highly variable notion.
but always better has its basis in both that tall bump on the bell curve and that huge variation in the meaning of "feel better". it is not a moral or ethical valuation, it's a pretty straightforward observable fact of aggregate human behavior.
(now we get to always wrong -- but first -- i got a roofing contractor to talk to for a couple of minutes. be right back.)
always wrong is the discipline of making mistakes, keeping your energy and your spirits up as you discover every day that you're not done making changes.
i often tell geeks, don't worry so much about whether you're about to make a mistake, because i can pretty much guarantee you that you're about to make a mistake.
a lot of folks will seek to convince us that they have a system of laws that will prevent mistakes. that is the stock in trade of the huckster and the naif alike.
it *would* be nice if we had such a system of laws.

we don't.

making software for money is not remotely a closed problem with an algorithmic answer.
this holds exactly as true when we are talking about making changes to code -- a complex enterprise -- and when we are talking about making changes to organizations -- a complex enterprise.

it is near the heart of what complexity theory means by "complex enterprise".
the reason we focus so much on always small and always better is precisely because we know we will be always wrong.
and the knack of always wrong is in the simple acceptance of that fact. it is making decisions knowing with confidence that you will make them differently again later.
it's why our most fundamental statement or our ideas is "embrace change". we don't embrace change because we love change so much, we embrace it because it is the entire point of the enterprise.
we stand at this cusp, where the movement has taking us from exclusively focusing on the made to extending our focus to the making and extending it again to the makers themselves.
and making changes that work -- in code, in orgs, in processes, in teams, in our selves and other individuals, it's just this mantra: always small. always better. always wrong.
here's that blog article you've been waiting to counter: "Always Small, Always Better, Always Wrong".…
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Michael D. Hill
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!