(2021-05-25) GeePawHill: Path-focused Design

GeePaw Hill: Path-Focused Design. "Path-focused design", of stories, architecture, code, is design that understands that we can only reach a distant City on the Hill by taking one stride-limited shipping step at a time.

In the software design theory of the ’80s and ’90s, the complete examples tend to share three features: small scope, single-thread construction, aimed at a fixed and final target. The issue is that, like nearly all strategists all the time, they were fighting the last war. None of these features, so true in the world of the ’70s and ’80s, holds true in the modern professional software circus. They’re just not there.

The far larger scope means it takes far longer to get to the CotH.

To go faster, we use many more people, working in parallel, and having to address issues of synchronization. And the lifecycle of modern apps is far longer, requiring lots of concomitant post-release change.

In addition, the funding models in software are also a huge factor

When someone sets a software problem, I instantly start working out the solution in my head.

I imagine a finished solution, then decompose it into a bunch of finished parts

Ninety percent of the problems we actually face as geeks aren’t "solve this problem eventually, starting from a clean page", they’re "make our existing solution do this also (or instead) as soon as possible".

Path-focused design means that we have to design not just the finished parts, but the "shipping stride-limited steps" needed to get us there, and that will mean taking steps that involve shipping parts that sometimes don’t even resemble the finished parts.

"Shipping stride-limited steps" is a mouthful. It’s the placing of two constraints on our definition of a step. 1) It must be smaller than a certain size in elapsed time. 2) It must be independently shippable at the moment of completion.

Now, as soon as programmers or producters hear constraints like these, they declare them to be impossible to meet. They’re not impossible to meet, they really aren’t. Rather, the standard faux-efficiency model we use in the trade is kicking in and making it seem that way.

What’s going on is that folks are secretly holding on to two other constraints, two that path-focused design explicitly does not hold.

Extra faux-efficiency constraint #1: Each step must create a "final part". Another way to phrase this, no step is allowed to change anything that was changed in a previous step already. This is the finality constraint.

Extra faux-efficiency constraint #2: Each step must add user-detectable value.

that’s why path-focused design is different from traditional design. It seeks to meet all four constraints, but when it can’t, it settles for three, and when it must, it settles for just two: "stride-limited" and "independently shippable".

I’ve written about this a lot, using different language. If you’re a producter look at my iterative user value article. (2020-08-18) GeePawHill Iterative User Value

What’s the positive difference, the benefit?
There is zero synchronization. Each step is independently shippable.

What’s the negative difference, the cost?
Someone had to think of it. We are changing the same code twice

Now, I’ve been talking about "path focused design" as if it were a new idea. But of course, it’s not.

Focusing on the path to the City on the Hill is incredibly important for efficient software development. If we always and only pay attention to the CotH itself, we’ll create slow-moving bureaucracy-laden high-risk development processes, & that’s not a cost we can afford to bear.

And one more tiny thing before we go: This looks like it’s about changing code or changing product, and it is. Because it’s about changing anything. Whatever the domain of our City on the Hill, we need stride-limited shipping steps to get there. (Theory of Change)

Update: see MMMSS.