I mentioned endpointing yesterday. I’m always using geepaw-isms & expecting people to know what I mean. Endpointing is over-focus on eventual destination. In s/w, it’s seeing development as a long trip to a known destination on a known map.
John Winthrop, a few centuries back, used "the city on the hill" to describe an endpoint, in his case for the puritan colony. The metaphor, of a trip to a place, is as natural as any human expression. But it contains within it some very misleading ideas. It’s easy to slip from "going from here to an imaginary place" into "going from NY to LA". (cheap shot about imaginary LA elided.) the nature of complexity is such that predictability (Y-axis) mapped to time (X-axis) isn’t remotely linear. It has a very sharp knee. Predictability gently curves slightly downward as we move out in time, then suddenly drops precipitously.
Where’s that drop-point in s/w? Well, we could argue, of course. It’s clearly before we get to 90 days. I’d argue it’s much further left. IME within a few weeks, predictability virtually vanishes. YMMV, but whatever u take the value to be, watch it and remember it and attend.
Now, the city on the hill of our software efforts is nearly always further away than a few weeks, usually further away than a quarter. No worries, we say: we’ll break the duration into periods shorter than knee and we’ll add them all together. We’ll decompose.
Again, this is a natural choice. Unfortunately, it’s not a rational choice in the face of genuine complexity.
You’re thinking of each decomposed segment like a line segment, and you will line them all up to get from NY to LA. But you’ve forgotten some critical things.
1) The segments may be of fixed length in time, but they aren’t of fixed length in productivity. We account for this w/over-estimates. Or rather, we try to. But the unfixed production length isn’t the only problem.
2) The segments are of variable length AND their of variable orientation. They all start where the last ended. But even mild unpredictability means they head off at angles different from the earlier direction. The consequence is that we’re continuously being thrown "out of line" by various amounts.
3) The city on the hill is not actually LA on a roadmap. It is an idea, a schema, a theory, a vision. And just as we’re moving, so is it. It isn’t just the market that changes, it’s really everything related to our vision, including us.
"Endpointing" hurts us more than it helps us. The ideas built into it carry over into our process & planning in nefarious ways.
It encourages us to make commitments we can’t possibly keep. That in turn encourages lots of very counter-productive behavior. Death marches. Contract-style litigation. Factional war. Blame-shifting. The list goes on and on.
It encourages us to mislead. We mislead ourselves, each other, our customers, our shareholders. I work hard to avoid words like "evil", but this is a kind of structural madness. Because it sets up zero-sum, all wins for one are losses for others. The pie never grows, it’s only distributed differently.
How do we change this?
Well. A start. We need to, i’m reminded of the great New York magazine competitions, "block that metaphor!" software development at even moderate scale is never "NY to LA in 60 days". Never. I’m sore tempted to propose "exploration", but even that doesn’t cut it. Pick an arbitrary average scumbag explorer, say lewis & clarke. They had a city on the hill, but it was really just "west to the pacific". They did not know the way. They often didn’t know where they were that’s the good part of that metaphor. They optimized for stepping, for sustenance, for collaboration, for motivation. They embraced change rather closely.
The bad part of the exploration metaphor: land is land. It changes very slowly. It almost never drops out from under you. Reasonably well-scouted routes don’t suddenly become impassable. And most tellingly, lewis & clarke got to move the same stuff every day.
In software, the stuff we move gets bigger and different every day. It’s as if we built at every camp site a new, larger, different, more populous, house, then set out the next day to move it further along.
So I can’t fully embrace the exploration metaphor, because radical unpredictability & ever-increasing burden aren’t there.
Still. It’s a start. How does this add up to advice?
Well, i’ve said it. Optimize for small doable/undoable steps. Optimize for motivation, the engine that keeps us going. Optimize for collaboration, the source of most of the ideas we’ll need. Optimize for sustenance, harvesting value as we go. Some keys:
- don’t waste an inordinate amount of time arguing about what color to paint the walls in the city on the hill.
- choose steps based on "not definitely backwards" rather than "leads in a straight line to target".
- believe that the land will in fact drop right out from under you, so always remember undoability.
- give 75% of your attention to this week, 20% to this month, and 5% to this year.
- harvest every inch of value you find every step of the way by handing it to customers.
The opposite of "endpointing" is "next-stepping". Train people in these ideas, AT EVERY LEVEL. They’re relevant in code, process, planning.
And the "NY to LA"? Block that metaphor.