One At A Time
But One What?
Whatever principles I try to live & work by, I try to apply them just as much & as often as possible. Yesterday, though, a lawn chair taught me a valuable lesson about the principle of flow.
The Principle of Flow states that, all else being equal, smaller batches of value more frequently is worth more than that same value delivered in fewer, larger batches. You’ll find the Principle of Flow working every corner of Extreme Programming—software design, planning, testing, integration, deployment, conversations—every corner.
Lawn Chairs
Back to the lawn chairs & my obsession about principles. I was getting 2 chairs out of the box in which they shipped. First I said, “I’ll get grab one first because that will be easier.” Followed quickly by, “Hey, this is the Principle of Flow. Aren’t I a good boy to be applying my principles throughout my life? Talk about integrity!”
Followed by 10 minutes of thumping & swearing. Every time I moved the top chair, the bottom chair would shift. The shift deformed the cardboard box (which I couldn’t destroy), causing the top chair to be more firmly stuck. (At this point a diagram would likely help, but that seems overkill for the eventual conclusion—trust me that moving one chair caused that chair, indirectly, to be more stuck.)
Principled action can be extremely expensive if you’re dumb about it.
Eventually I thought, “Well, I wonder if I can shift the bottom chair?” One tug & both chairs popped right out.
More obscenities. Okay, what just went on here? What was wrong with my principles or my interpretation of my principles?
One [X] At A Time
The problem is that tricky phrase, “…all else being equal…”. In this case, 1 chair at a time wasn’t at all equal to 2 chairs at a time. 1 chair at a time caused nearly infinite friction, infinite at least from the perspective of my aching back. 2 chairs at a time had no friction, just the (light) weight of the chairs.
The bigger batch reduced effort. That may be the rare case. Incentives abound to thoughtlessly increase batch size. I don’t want to make a habit of increasing batch sizes when I encounter trouble. But I need to be aware of the twin possibilities of increasing & decreasing batch size. I need to be prepared to solve for X in “One X at a time”.
(The other lesson is about hubris. Just because I have some principles that seem to work in most situations, I don’t have it all figured out. I need to observe, pay attention, & think.)
There are tons of examples like this.
Tool efficiency, where you don't want to swap tools every minute but rather use the same tool with one kind of job until the job is done, then move to the next tool for the next job.
Alignment, where in order to construct parts you need a greater whole prepared, like plumb lines or foundation stones.
Getting smaller parts done, does not mean smaller parts are useful in themselves.
I built a bonsai cultivation area, we burned all the wood at the same time. We didnt burn one, install it, then burn the next and install it. We burned all the wood, installed all the wood in sequence.
I feel like this applies to the project I'm working on. For contractual and compliance reasons we have a lot of "paperwork" around releasing application versions to staging and production environments. It means trying to release very small changes has a huge overhead, and thereby a tendency to group things together in larger releases.
The better solution here would probably be to reduce the friction caused by the paperwork. It is not something I can do as an individual, but I could probably invest some time in convincing those who can make it happen.