I can derive 3X: Explore/Expand/Extract from the Kelly Criterion. Explore: make more, smaller bets when the probability of failure (experiment returning the undesired outcome) is high & the payoff is high.
Expand: make one bet at a time when the cost of failure is total & the probability of success is reasonable.
Extract: make a few large bets when the probability of success is high & the payoff (as a percentage) is low (the absolute numbers will be huge compared to Explore).
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The goal of software design is to create chunks or slices that fit into a human mind. The software keeps growing but the human mind maxes out, so we have to keep chunking and slicing differently if we want to keep making changes.
This implies that software design is a human process with technical support, done by humans for humans. As shiny as the technical support is it took me a while to acknowledge that messy people stuff.
I’ll add that “fits into” and “maxes out” are metaphors and not precisely true, but they help make sense of a healthy, growing urge to re-design. Knowledge is not a quantity & the brain is not a space & we work together.
As part of yesterday's Invitation to Systems Thinking workshop @jessitron prepared a short play from which the students would draw various diagrams of the software development system described. At one point the manager says, "This is not acceptable," and it hit me hard in layers.
Layer 1: of course it's acceptable. You've been working like this for months, maybe years. You've accepted it all along.
Layer 2: of course it's not acceptable. If you keep going like this you'll be out of business in a year or two, maybe sooner. Something does need to change.
I've played guitar and sang for 50 years. I rarely play for anyone else. I'm haunted by the feeling that I need to be better before exposing myself to others. (Deep roots to this--story for another day.)
I have a love/hate relationship with practicing. Sometimes I do it and love it, the sense that I know where the boundaries are and I know if I'm doing it right. Sometimes I do it and hate it, since I could always be faster and cleaner.
Often I don't practice. It's exhausting not knowing whether I'm going to drift into OCD bliss or savage myself. And then I beat myself up for not practicing. (Don't worry, we're getting to the connection/redemption part of the story.)
My disagreements around planning seem to revolve around metaphor: a plan is X. Different answers for X lead to different behaviors and different evaluation of outcomes.
“A plan is a prediction of the future” is a common metaphor. Nobody out and says that, because it is absurd in an atmosphere of substantial change, but that’s how some folks act.
“A plan is a chance to escape a local maximum” leads to different plans and planning. This plan is about stepping back from execution to see if there is a different path entirely.
While working on #TidyFirst this visualization of why software design is a human relationship problem popped up. Thread
The cliche product/engineering split has someone with an idea waiting for the behavior of the system to change so they can analyze feedback. These are the “waiters” (seems enough time has passed to reuse this word).
The makers actually change the behavior of the system. They also change the structure of the system, because the structure affects how they can change the behavior.