Coleman McCormick

Archive of posts with tag 'Systems'

✦
October 17, 2024 • #

Gratitude and Resilience →

Gratitude is how we maintain the fragile, critical systems of relationships that come to our rescue when things go bad. Strong institutions get that way through the effortful work of the grateful to nurture them on.

✦
✦
August 29, 2024 • #

The Wisdom of Restraint →

Riffing on one of my favorite quotes, from Calvin Coolidge:

✦
✦
✦
✦
✦
✦

The Simplest Thing

September 20, 2022 • #

When working through problems, the most impressive creators to me aren’t those that divine an entire solution in their brain for an hour, then slam out a perfect result (spoiler: this doesn’t exist outside of the occasional savant). I love to watch people who are great at avoiding the temptation to overcomplicate. People who can break problems down into components. People who can simplify complex problems by isolating parts, and blocking and tackling.

I enjoyed this, from an interview with Ward Cunningham (programmer and inventor of the wiki):

It was a question: “Given what we’re trying to do now, what is the simplest thing that could possibly work?” In other words, let’s focus on the goal. The goal right now is to make this routine do this thing. Let’s not worry about what somebody reading the code tomorrow is going to think. Let’s not worry about whether it’s efficient. Let’s not even worry about whether it will work. Let’s just write the simplest thing that could possibly work.

Once we had written it, we could look at it. And we’d say, “Oh yeah, now we know what’s going on,” because the mere act of writing it organized our thoughts. Maybe it worked. Maybe it didn’t. Maybe we had to code some more. But we had been blocked from making progress, and now we weren’t. We had been thinking about too much at once, trying to achieve too complicated a goal, trying to code it too well. Maybe we had been trying to impress our friends with our knowledge of computer science, whatever. But we decided to try whatever is most simple: to write an if statement, return a constant, use a linear search. We would just write it and see it work. We knew that once it worked, we’d be in a better position to think of what we really wanted.

The most impressive software engineers I’ve worked with have a knack for this type of chewing through work. The simplest thing usually isn’t the cleanest, fewest lines of code, fewest moving parts, or the most well-tested. Simple means “does a basic function”, something you can categorically check and verify, something a collaborator can easily understand.

Sometimes you just need to first do the Simplest Thing before you can find the Correct thing.

✦
✦

Scenes, Pattern Languages,and Nested Systems

August 22, 2022 • #

Last week I picked up Scene and Structure on a recommendation I saw from Nat Eliason. I’ve seen him mention experimenting with writing fiction, which this book is about — the process of narrative structure, staging scenes, the balance between scenes and “sequels” to maintain coherence and tension through writing novels, which is the author’s background. I’ve thought about testing the waters with fiction writing, even if I never publish it anywhere. I think the NaNoWriMo happens in November, so maybe I’ll make a plan to give it a shot during that and see what happens.

Anyway, I’m not necessarily interested in the structure of fiction for myself in learning how to write it. For one I just find it interesting how “formulaic” in a way that all narrative fiction is, from novels, to TV, to films. Once you read Scene and Structure, it’s hard not to notice the mechanical elements playing out. You can watch a TV show and almost narrate yourself the structural elements as they happen. The point of Bickham’s guidance is not to distill every writer into following the same exact formula for everything they write, but rather to see the elemental components of storytelling with clarity, allowing you to see the skeletal framework of fiction. Think about cooking. Yes, it’s about recipes and ingredients, just like stories are plot elements and sentences. But becoming a great cook is more than about knowing lots of recipes and ingredients; great cooks know why particular ingredients show up in recipes together, what each is contributing to a dish, and they can assemble subgroups of ingredients in repeatable, predictable ways. Compelling writing — just like compelling cooking — requires knowledge of a structural hierarchy. A mirepoix of celery, carrot, and onion is a known, functioning collection of aromatics that works well in many many dishes. It’s a building block of building blocks. In narrative, if all you have is action-packed scenes connected one after the other, without a sequel in between for characters to digest what happened and mull over decisions, you leave readers confused and overwhelmed. And there are parallels with systems of all sorts, not just cooking.

One of the things I’m most curious to consider with this book is how well the principles could translate to nonfiction writing. Certainly if you read well written narrative nonfiction — Barbara Tuchman, John McPhee, David McCullough — they’re using many of these similar tactics to establish PoV “characters”, create tension in the narrative, and to find meaning in events, versus just “this happened, then this, then this”, which you could fall into easily writing something like history, which is literally a retelling of events.

I’d also started reading Christopher Alexander’s famous work A Pattern Language, something I’ve had on the shelf a long time and have been looking forward to picking up. I’m probably 50 pages into it so far.

What’s interesting are the similarities between these two books. I hadn’t bought either for the same reasons, but the common threads are certainly there. A Pattern Language is Alexander’s guidebook to cities, neighborhoods, architecture, construction. The idea is that composing these places that people live is an exercise in thinking in building blocks. He lays out dozens of reusable components or themes in architecture, from empirical study of what works and why. Well lit rooms, places to sit, greenery in the right places, putting benches next to gardens. Each on its own seems like an obvious thing, since these are components we see constantly around us. Though I’m not far in yet, and haven’t read any Alexander before, I see the purpose isn’t to tell you that well-lit rooms are a good idea, but to see these components as LEGO blocks for design. If you develop a language of patterns for your own work — even something like software — when faced with what to put where in a new design, you can refer back to your book of patterns and find subcomponents that’ll work well in that situation, based on the goal you have for a particular feature.

Thinking about these systems as “languages” is interesting. A language is hierarchical just like the systems these two books present for fiction writing and architecture. You start with letters, build those into words, then phrases, sentences, paragraphs, and so on. You can’t simply insert new elements into a language from the top without considering how your elements nest together and interact with the surrounding existing elements. This is why top-down “designed” languages have never worked. Even attempts to guide, restrict, or control natural languages have largely failed. The French famously have a government body responsible for maintaining what “real” French looks like. Has that worked? Do French people refer back to a government website to determine to some new vernacular or not?

The similarities between systems like these is fascinating to me. In both cases, fiction and architecture, the systems of patterns are developed over time based on empirical evidence of what works. Writers didn’t invent Bickham’s structure from whole cloth centuries back; the concepts he presents have evolved gradually over time. The way writers wrote even 200 years ago bears little resemblance structurally to what a novel looks like today. Writers over time learned what readers wanted, and innovated around the edges while conforming to norms of structure that were mostly predictable.

In the same way, Alexander refers to “the timeless way of building”. Most of the individual building patterns he presents he did not invent. They’re components for comfortable living that humans developed, in some cases, millennia ago. His mission isn’t to tell you new things, but to present a framework for ordering and assembling the things we know work into a cohesive hierarchy.

✦
✦

Measuring Productivity

July 30, 2020 • #

Florent Crivello had a short thread on Twitter contrasting the effectiveness on systems between Goldratt’s The Goal and Bill Walsh’s The Score Takes Care of Itself. One of the replies linked to this piece from Scott Young I found interesting for a couple of points on measuring productivity of systems.

The idea in books like The Goal and its modern IT counterpart The Phoenix Project present the process management paradigm of the Theory of Constraints. The shortest possible version of the TOC says that the output of a process or system is limited to the volume permitted through its narrowest constraint — a chain is only as strong as its weakest link. You could increase the efficiency, quality, or speed of all the remaining steps and not increase overall output if you’ve got a bottleneck.

This post first debates whether you’re better off measuring inputs or outputs to determine a system’s effectiveness. Books like The Goal seem to state that it’s all about the output; outcome over everything else; ends versus means. But Young makes the point that measuring only outputs is often not granular enough in complex systems to tie the application of a new technique or system to the change in outcome:

I’ve met a few consultants that have the following business model: I help you implement some idea for your business. If profits go up, you pay me a percentage. If they don’t, you don’t owe me anything. Win-win, right?

The trick is that businesses with volatile income will have many ups and downs. Most of that is random noise. Now imagine a consultant shows up with worthless advice—pure placebo effect. Half the businesses he consults go up, and he gets a hefty cut of the upside. Half go down, and he gets nothing. He makes a fortune, even though the advice is worthless.

He also references the Hawthorne effect, a phenomenon in which individuals modify their behavior in reaction to awareness that they’re being observed. If a consultant comes in to implement a new process, or you make a new “expert” hire that starts changing things, and results get better, how do you know there’s a causal link? What if the act of bringing in the consultant or new hire was what spurred the uptick, not their “improvements”? (People start working harder when there’s a consultant coming around, or when there’s a new manager in their department)1

Another dimension orthogonal to input-output is scale — big, long-term items, or the activities happening at the individual task list level:

Productivity measurement scale

Plotted on two axes like this, I’m reminded of the Eisenhower Matrix for thinking about task priority:

Eisenhower matrix

Just like how with time management we want to orient ourselves toward the “not urgent / important” quadrant, in the productivity matrix we want to do things that push us toward the right spot in “big picture / output” quadrant. Not everything worth doing to position correctly on the scale-to-throughput chart falls in the same place. Just like with the TOC, bottlenecks exist at various stages and differ in levels of effort to widen or correct them. The “ROI” on a process change could by high-R, low-I, or the reverse. The effectiveness with which you can widen the bottleneck is often (but not always) decoupled from how much effort it takes.

I like Young’s framing here on what to do and how to measure. If we’re seeking areas we can clearly measure, we know those are unlikely to be in the upper right quadrant. The lower left is great for aligning your measurements because of the clarity and speed possible at that scale. This is the best of the diagrams to explain a measurement strategy:

Ease of measurement

So as he says in the post: “pick a few metrics that will estimate what matters.” You want to figure out measurable items that directionally vector toward where you want to be — toward big outputs.

With a model like this, you can select tight, measurable metrics that aim the right direction, then make adjustments to course correct. Metrics that live in the lower left quadrants should have tight feedback loops, giving you signals on what adjustments are needed. Like all well-designed, robust systems, you want to build a productivity measurement model that’s adaptable, using trial and error to improve.

Check out Scott Young’s full post; it’s excellent.

  1. I suppose through a purely outcome-driven lens, these examples got the desired outcome, regardless of how it was achieved. Though I don’t think in cases where this happens that anyone is savvy enough to realize true causes. 

✦
✦
✦
✦