Thread by @sarahmei

So! In case you missed it, yesterday while my plane was delayed, I read the 4-page preface of a book on software design.

It took me three hours to extract from four pages of prose the two fundamental disagreements that I have with its ideas.

External Tweet loading...
If nothing shows, it may have been deleted
by @sarahmei view original on Twitter

It took so long for a couple of reasons:
- I was having a beer
- the social waters were tricky to navigate (plane was full of BigCo execs)
- the book’s author didn’t put the two assumptions I disagreed with out in the open. I had to unearth them & figure out why I disagreed.

At just four pages long, I have to say - it takes a peculiar kind of genius to pack in so much wrong. There’s probably a great German word for simultaneous horror and admiration.😅

I’ll summarize what’s wrong & then talk a little about the rest of the book, & why I kept reading.

MYTH 1: The goal of software design is to break large problems into smaller ones.

REALITY: although it’s still taught in schools this way, it’s much too narrow & only covers a fraction of useful techniques.

The goal of software design is to reduce the cost of future change.

Software design is a holistic activity that encompasses code organization, testing strategies, communication, tooling setup, reviewing code, & refactoring.

All these activities influence & feed off each other. Their emergent behavior determines how much effort change is.

MYTH 2: perceived “10x” differences in programmer productivity are due to skill differences between the programmers.

REALITY: there are at least two types of programmers - the ‘genius’ ones who can keep a whole complex system in their head at once, and the rest of us.

A ‘genius’ programmer can make changes faster than others, as long as they can hold the whole system in their head. But if you let them do that, then when the system gets too big or too complex or you want other folks to work on it, you’re fucked.

The crucial realization here is that the ‘geniuses’ ARE NOT MORE VALUABLE than the folks who CAN’T hold the whole thing in their head. Those folks have the habits and the design instincts to communicate intent, and to carve out smaller bits to work on - because they have to.

When a project gets too big for anyone to keep in their head, you can’t retrofit those habits, and good luck getting the ‘genius’ to write anything useful down. Whatever context others need has long ago receded into their unconscious.

You need both of these types on a team. I think of them as gardeners and forresters. They both have crucial insights on the project. But they need to understand each other, and learn from each other.

The forresters need to learn to be tidy and methodical, and to label rows in a garden plot. The gardeners need to learn to see how the garden plot they’re working on right now fits in to the context of a larger ecosystem.

It’s not a problem of “upskilling” the gardeners to make them all into forresters. That’s a recipe for starvation. Yet that’s what this author assumes - that the people who appear less productive just need to be upskilled so they’ll be more like the 10xers.

The author never even considers the possibility that their concept of “productivity” might be culturally constructed (from back when most programmers were forresters) and therefore doesn’t really work in the new world we find ourselves in.

And calling these folks ‘genius’ or ‘wunderkind’ programmers doesn’t do them any favors. Under those circumstances, it’s easy for them to turn to arrogance when other people can’t understand what they’re doing.

To reiterate again - we need forresters! But we need ones who understand their limitations and appreciate what gardeners bring.

If you’re a forrester, your saving grace is going to be understanding how to document, chunk, and organize your software differently.

That is - I think - what this book is attempting to do. It assumes everyone is a forester or forester-in-waiting & explains how to design software so that it can be worked on (and understood) piece at a time rather than all at once.

It completely ignores, however, that _not everyone needs this_. Highly skilled gardeners have a better version already that doesn’t assume your goal is to understand the whole, & can find this interferes.

(This is similar to how agile is a structured set of interactions that a group of highly skilled communicators wouldn’t need to be told to do, and would find unnecessarily restrictive. But that’s a rant for another day. Maybe @pearconf.)

So what do you do if you can’t hold the whole system in your head?

If you’re a forester, you apply Traditional Software Design™️ (like in this book) to make smaller systems, so that you can go back to holding the whole thing in your head.

If you’re a gardener, you apply automated testing, careful naming, documentation, code review, and collaboration to make sure you don’t _have_ to know the whole system in order to make changes.

This is why we need both types of folks! Sometimes it makes sense to separate systems - the team is growing too large, or even the gardening techniques aren’t enough.

But separating effectively requires a lot of gardening ahead of time, to make sure something cohesive results.

People aren’t all forester or all gardener. Like everything else in life, it’s a spectrum, and our place on it can move back & forth even inside a single task. Most people have a range they’re comfortable in.

But it is a spectrum - not a gradient. You don’t start out as a gardener and then, as you get more experience, become a forester. Experience expands the range you’re comfortable in, from wherever you start.