Oddly Influenced

Welcome to oddly influenced, a podcast about how people have applied ideas from *outside* software *to* software. Episode 19: /Seeing Like a State/, part 3: users and clients

In the previous two episodes, I’ve been summarizing Scott’s descriptions of why “schemes to improve the human condition that failed” did exactly that: failed. In the previous episode, I described purveyors of such schemes as being possessed by a need to favor efficiency, order, power, simplicity, correctness, universality, and distance over actually… well, improving the human condition.

In this episode, I hope to give you some helpful hints about *actually* improving the lives of the users of the software you create. Or, if you’re the kind of “change agent” or “coach” I used to be, the lives of the, uh, victims of your consulting.

Remember that these are only my ideas, that might give you ideas. I don’t claim expertise or authority.

It’s a commonplace that “the people on the ground” resist change. Scott would argue that the reality is more complicated. He does provide many examples of planners and officials claiming the people on the ground are resisting some High Modernist plan. But he suggests there’s an institutional, professional, and personal bias toward falsely believing in resistance. Scott gives three reasons:

First, the more deference the specialist gives to the person on the ground, the less important the specialist is – and the less important is the whole institutional structure the specialist comes from. Lower personal and institutional status is not in the specialist’s interest.

Second, remember that High Modernism is skeptical of the past. The way people used to do things is, practically by definition, *wrong* in some way. It’s hard to listen to people who have been Doing It Wrong forever.

Third, the practical knowledge the people on the ground use to successfully navigate their world isn’t easy to formalize (especially in a computer program). This is not a message someone in charge of implementing a formal plan typically wants to hear.

Scott points out that the people typically characterized as resisting change actually embrace all kinds of change. Quote: “traditional peoples will embrace techniques that solve vital problems. Sewing machines, matches, flashlights, kerosene, plastic bowls, and antibiotics are only a tiny sample of the products that solved vital problems or eliminated great drudgery and were thus readily accepted.”

This is true not just of adopting off-the-shelf solutions but also of changing crucial patterns of work. Scott quotes the conservative philosopher Michael Oakeshott as saying, “The big mistake of the rationalist – though it is not inherent in the method – is to assume that ‘tradition’, or what is better called ‘practical knowledge’, is rigid, fixed, and unchanging – in fact, it is ‘preeminently fluid’.”

An example Scott gives is potato growers in the Andes. Let’s start with the background against which change happens. The growers don’t only grow a single variety of potato. Instead, they make use of many ‘cultivars’. That’s a word, possibly short for ‘cultivated variety’, that emphasizes how the varieties have been “genetically engineered” by careful breeding.

A single farmer might have 12-15 plots, each of which is understood in detail. They have to be, because there’s lots of variation in the plots, depending on their altitude, soil, slope, orientation to the sun and wind, and so on. Each plot gets its own combination of cultivars. One plot might be completely planted with a single cultivar. Others might contain as many as 10 cultivars, possibly each in its own row, possibly all mixed together.

Why a mixture in a single plot? Why not just plant the best cultivar for that plot? Because it’s hard to say what will happen in a growing season. The patterns of rainfall and temperature, for example, aren’t the same from year to year. So the savvy farmer plants in order to get consistent results from a changing environment. “Each cultivar is a well-placed bet in its niche.”

That focus on consistent results grabbed my attention. Something like 30 years ago, I got interested in statistical quality control. One of the people I learned about was Genichi Taguchi. In his day, it was common to use statistically-informed experimentation to reduce variance in a controlled environment: that is, the goal was for a particular factory to be changed so as to achieve ever narrower tolerances for, say, the thickness of the washers it produced. Taguchi was a pioneer at experiments that aimed to produce consistent results in *differing* environments. An example our professor used was an automobile engine that behaves consistently at different altitudes. Another example could be Andean potato farmers who aim to get a consistent crop despite the weather. They’re not *disinterested* in improving their yield, but they’re also interested in consistency. Consistency matters a lot if a bad harvest could ruin you.

High modernist agricultural plans take the non-Taguchi approach. They aim at reducing variation in the environment, typically by simplifying it. (Planting only one crop, consistent use of fertilizer, and so on.) Because of that, the plan is not robust against changes in what can’t be controlled, like the weather. The result is often *increased* variance. Most importantly to the people on the ground, the worst case gets worse.

Against that background, here are the kinds of experiments the potato growers do. “The variety of cultivars makes for local experimentation with new crosses and hybrids, each of which is tested and exchanged among farmers, and the many landraces of potatoes thus developed have unique characteristics that become well known. From the appearance of a new variety to its substantial use in the fields takes at least five or six years. Each season is the occasion for a new round of prudent bets, with last season’s results in terms of yield, disease, prices, and response to changed plot conditions having been carefully weighed. These farms are market-oriented experiment stations with good yields, great adaptability and reliability.”

They’re not doing statistics, probably because they don’t have the technology but also perhaps they’ve read XKCD comic number 2400, “Always try to get data that’s good enough that you don’t need to do statistics on it.”

I want to highlight that the experimentation of people on the ground is *slow*. The High Modernists don’t usually have the patience to wait five to six years. Their on-site experiments tended to last only one or two growing seasons, which isn’t enough time to see enough of the natural, uncontrollable variation.

This slow, persistent, continual experimentation ties into a key concept of Scott’s: mētis, a Greek word that Scott describes as “the kind of knowledge that can be acquired only by *long practice* at similar but rarely identical tasks.” It is most appropriately used in “similar but never precisely identical situations [that require] a quick and practiced adaptation, [one] that becomes almost second nature to the practitioner.”

Mētis is a deeper idea than just “rules of thumb.” For example, Native Americans taught early colonizers to “plant when the oak leaves were the size of a squirrel’s ear.” That rule is really, though, just a simplified representation of the usually-orderly pattern of the arrival of spring. First – usually – the skunk cabbage appears, then the willows begin to leaf, then the red-wing blackbird (a migratory species) returns, then there’s the first hatch of the mayfly, and then the oak leaves reach the size of a squirrel’s ear. Because the native farmer is attentive to all of that, she can can know if this spring is “funny”, in which case it might be prudent to wait a little longer.

That is, an important part of mētis is detecting outliers. Writing of firefighters, rescue squads, paramedics, and the like, Scott says, “Each [incident] is unique, and half the battle is knowing which rules of thumb to apply in which order – and when to throw the book away and improvise.”

Notice how intensely *local* the planting mētis is. Not only is it specific to a particular ecosystem (the upper northeast of the USA), but it is also local *within* the ecosystem. If you looked at a farmer’s almanac for planting advice, its advice would be to plant on a certain day. That day is supposed to apply to a broad area. (Which means, by the way, that it has to be conservative, since planting too early in this case is worse than planting too late.) But the native’s mētis would give different planting dates for a northern than a southern exposure, or for different elevations. It’s the oak leaves *right here* that matter, not some average of oak leaves across New England.

This is characteristic of mētis. Another example is from Mark Twain, who wrote /Life on the Mississippi/, a book about his, well, life on the Mississippi River as a riverboat pilot. Scott says, “Part of [riverboat pilots] knowledge consists of rules of thumb about surface features that may signal shallows, currents, or other navigational hazards. Much of it, however, consists of a quite specific familiarity with their particular stretch of the Mississippi at different seasons and water levels – knowledge that could have been gained in that particular place only through experience. Although there is something that might properly be called a knowledge of rivers in general, it is a quite thin and unsatisfactory knowledge when it comes to making a particular trip on a particular river.”

Mētis is not ideally compatible with hopping from job to job every couple of years.

Another problem with mētis is that it’s extremely difficult to learn without *doing* the thing you’re learning. It would nice to be able to learn to ride a bicycle by reading an instruction sheet, but that’s just not going to happen.

That’s not to say that such learning is solitary. When you’re learning to ride a bike, someone who already knows can watch you and give you advice. My favorite story along these lines is from when my wife used to teach veterinary students how to examine sick dairy cattle. Cases come in, and they’re assigned to particular students. Every day, first thing in the morning, the student does an examination of the cow and writes down their analysis and treatment plan for the day. The first thing to write down is three bits of information: is the cow “bright* or dull”, “alert or depressed”, and “responsive or non-responsive”. To reliably make the “bright or dull” decision, the student must develop an appropriate mētis. The way this is done is through rounds.

The clinician (that is, the professor, my wife, Dawn) and the students go from case to case. The clinician looks at each patient’s record and corrects the student where needed. For some reason, students usually err on the side of saying a cow is bright when it’s actually dull. My wife would then say something like “that cow’s actually dull. Look, it’s not cleaning its nose”. (Cows clean their noses pretty much all the time, using their tongues. Despite your likely reaction, it’s actually sort of charming.) Anyway, all of the students now acquire the rule “if the cow looks bright, but it’s not cleaning its nose, it’s dull.”

They move to the next animal. Maybe this patient’s student classified her as dull, but then Dawn says she’s bright. The student might say, “But it’s not cleaning its nose!” And Dawn will say “But her ears are perky.” Another clause gets added to the rule. An algorithm is being built.

Eventually, the students learn to make the correct judgment. That is, they give the same answer as Dawn would, but also that any other clinician would, even someone trained at a completely different vet school.

Importantly, by this point, the students have *lost the rules*. Scott says mētis “becomes almost second nature to the practitioner”. Drop the “almost” for this case. The students have no conscious access to any algorithm. To them, as it is to Dawn, a cow simply *looks* bright or dull. They can’t *not* see it. When asked why a cow is “bright”, they’re forced to do the equivalent of explaining why a joke is funny. You can do it, but it’s a conscious, after-the-fact invention. It doesn’t capture anything like the gestalt, the experience that caused you to laugh. At best, an explanation can nudge the listener toward a bit more understanding. But half the time, I think such explanations are just a way to throw a sop to the rational part of the mind – to get it to shut up so we can all move along to getting new experiences instead of talking this one to death.

Now, at this point I need to say that sometimes High Modernist replacements for mētis are good. Really good. Physicians used to taste urine to diagnose diabetes. In 1674, Thomas Willis described diabetic urine as “wonderfully sweet as if it were imbued with honey or sugar.”

Fun! But a blood test is more precise. Although… the test *is* more expensive, and it *did* take much more effort to develop a reliable test than to acquire the tasting skill. Scott says a characteristic of mētis is that it is “as economic and accurate as it needs to be, no more and no less, for addressing the problem at hand.” Still, we’re better off today having tests than relying on taste. Nowadays, the mētis part of being a physician has, somewhat, moved up a level: part of the skill of being a physician is knowing which tests to order when.

Similarly, almost no one in the rich world any longer is able to clean clothing in a river with any skill, but washing machines are better anyway.

And, finally, improvements to mētis are made through something of a hill-climbing algorithm. They come from the combination and recombination of existing elements. That means you get ever better at plowing with oxen, but you don’t invent the tractor. (However, once the tractor is invented, it’s mētis-style experimentation that teaches farmers how best to use it.)

One final point about High Modernist schemes before I move to applications. Scott says, “Formal order […] is always and to some considerable degree parasitic on informal processes, which the formal scheme does not recognize, without which it could not exist, and which it alone cannot create or maintain.” He gives a number of examples.

* Example one. Brasilia is less of a formalized city than when it was built – its inhabitants have changed it – but it’s still unusually formal. So it’s interesting that 75% of the population lives in settlements that were not planned at all, that were originally founded by squatters who built houses on unused land outside the city. In fact, the city proper was projected to have 557,000 inhabitants, but it’s never reached even half of that. I bet the informal people outside the formal city are necessary for its functioning.

* Example two. The factories of the USSR were often required to produce a certain set of outputs from frequently inadequate inputs or tools. They had various informal systems that “surrounded” the factory and allowed it to carry on. For example, factories stockpiled nonperishable goods like soap, cosmetics, good wine, and fashionable clothes. They employed people who my German immigrant parents would have called “wheeler-dealers”. “When it seemed that the plant would fall short of the quota because it lacked a key valve or machine tool, these knowledgeable dealers would set off across the country, their small Trabant autos jammed with barter goods, to secure what was needed.”

* Example three is the “work to rule” strike, in which factory workers follow all the rules and regulations meticulously and do exactly – and only – what’s in their job description. Things grind to a halt or, at best, production drops drastically. The formal system only works because the people on the ground deviate from it.

In the next two sections, I’m going to describe some implications for both coaching and product design. Because there’s a lot of commonality between the two activities, I won’t repeat myself. That is, I won’t discuss implications of idea X for coaching and then again for product planning. Instead, I’ll sort the ideas into whichever category is most convenient for the narrative.

Let’s start with an example, though.

Whether you’re a “change agent” or an app designer, I hope you’ll thrill just a bit to Albert Howard’s description of water management in Japan. I think it’s worth quoting in full:

“Erosion control in Japan is like a game of chess. The forest engineer, after studying his eroding valley, makes his first move, locating and building one or more check dams. He waits to see what Nature’s response is. This determines the forest engineer’s next move, which may be another dam or two, an increase in the former dam, or the construction of side retaining walls. Another pause for observation, the next move is made, and so on, until erosion is checkmated. The operations of natural forces, such as sedimentation and re-vegetation, are guided and used to the best advantage to keep down costs and to obtain practical results.”

In my consultant life, I blundered into doing something like that. In the early days of Agile, there weren’t that many Agile coaches, so many companies had to fly us in, rather than ordering us as commodities from their local consultancy. I developed a standard engagement model, which was that I would fly to their site, spend a week there working with a team, finish with some recommendations, and then fly away for 4-6 weeks. Then I’d fly back, see how things had gone, work with them some more, make revised recommendations, then fly away again. The explicit assumption was that each trip would be less valuable to the company. If, at any time, they thought the next bit of my advice wouldn’t be worth my fee, they’d tell me and I wouldn’t come back any more.

I think that’s a useful model, better than having a coach constantly embedded in the team. Give them some time to think!

I was (and am) a fan of XP (Extreme Programming) and its focus on technical skills. (Those skills are, note, excellent examples of mētis. I always viewed with alarm the tendency in the early Agile days for people to build “code smell detectors”. It’s such a good example of a High Modernist squeezing a matter of trained perception - like bright vs. dull cows – into a formal framework. That the program will do a *worse* job than a trained human never seemed to stop people.)

Anyway, as an XP coach, I generally failed to apply the approach of the Japanese forest manager. There was a notion back then that a team should try all the XP practices together for a serious interval before making a judgment about XP, because a lot of the XP skills reinforce each other.

Here’s an example of reinforcement. One of the virtues of pair programming is that it supports test-driven design and refactoring. The idea is that, in any programming task, you’ll be faced with situations where it’s easy to trade short-term comfort for long-term pain. Should I *really* write that test? It seems hard. Should I spend time refactoring this code or move on to something else? The nice thing about pair programming is that it turns a private vice into a social decision: you and your pair have to look at each other and agree you’ll not do what you both know you should.

So the argument is that you likely won’t get good at TDD without pairing to push you up the learning curve. And you won’t see the full virtues of pairing unless you experience the way it helps you maintain discipline.

Nowadays, I’d lean toward a more gradual approach. I’d start with developing mētis with real-time collaboration and go lightly on TDD and refactoring. I’d probably start with “mob programming” (also called “ensemble programming”) instead of pairing. People tell me teams adopt mobbing much more readily than pairing, and my limited experience suggests they’re right.

I’d introduce TDD only for the simple cases – testing pure functions without any elaborate dependencies. I’d drop little hints about other virtues of TDD. Like, for example, if we got fed up with increasingly elaborate setup in our product code and started redesigning to simplify, I might point out that such frustrations *feel* more frustrating in test code, so TDD helps keep you from traveling all the way down the rathole before you realize you’re in it. But there will be time to learn about that later, when it will be easier and we have more mētis.

Similarly, I’d be less likely to suggest substantial refactorings. I’d suggest doing what your tools make easy, and spending maybe a half hour or so cleaning up code you ran into today that bugged you or was hard to understand.

How do I push back against my earlier self, who would claim that teams will cherry-pick only the easiest practices and never really get good at the totality of XP? The way I tend to push back against everything these days: I accept the validity of the objection, but am balancing that result against the likelihood they find XP too hard, or too foreign when it comes all at once, and reject it – probably by cherry picking only some of the original practices. Same result, different routes.

More pointedly, I’d say that following a formal structure (the practices of XP) rigidly “by the book” is hardly a way to develop the mētis of being a self-organizing team. So the current me wants to focus on the skill of reflecting on current process and improving it.

Because I’m old fashioned, I’d probably nudge the team to try pairing after they were comfortable with mobbing, and ask them to attend to whether they really need everyone working on the same problem. I’d be looking for them to develop mētis-style judgment about when to fly solo, when to pair, and when to work in larger groups (and what the composition of those larger groups should be). Really, what’s important here is getting better at coming to consensus about technical practices, and especially about avoiding common pitfalls:

First, rushing to judgment instead of having the patience of the Andean potato farmer.

Second, deciding based on abstract reasoning rather than personal experience or, better, team experience.

Third, confusing what you’re comfortable doing with what’s efficient or effective. Which I see *all the time*, including especially in myself.

Fourth, talking too shallowly about change. Remember, from bonus episode 14, how the Eskimos and Amish discuss how new technologies would affect the whole of their lives? Well, it’s a fact, I think, that TDD requires a certain openness to improvisation. It skews the balance toward being reactive over being proactive. Because ideas like “reactive” and “proactive” have strong emotional connotations – remember the “final vocabulary” of episode 4 – you’ll probably get in trouble down the line if you don’t talk about them now.

In any case, were I still in the business, that might be my default plan for an engagement. Very likely, the team would ruin my beautiful plan I mean assert their own agency – justifiably – and take things in their own direction. And that would be fine.

Something that frequently happened in my longer consulting gigs was that I increasingly consulted “up”. That is, I was usually engaged to do technical consulting with a team: teaching specific practices and showing them how someone stylistically Agile approaches problems. Over time, though, I’d end up talking to – coaching, really – managers or working on the interfaces between teams.

From Scott’s perspective, that was inevitable. I was working on introducing a formal-ish system within an informal one. The team’s working was “parasitic” on the surrounding organization and all of its unwritten rules. It was foolish of me to think I could stay away from it. Were I doing it again, I’d make that part of everyone’s expectations, instead of a role I sort of sidled into.

As applied to product design, Scott’s approach is pretty much in keeping with what I think of as the modern style. He favors taking small steps and treating each intervention (think release) as an experiment. He expects you will make mistakes and ought to reverse decisions, so you need to be ready for that. Scott would probably not be a fan of those various military commanders who supposedly burned the ships that had brought their army to the battle, so that their troops had no choice but to fight and win.

Scott expects people will use what you provide in unexpected ways. He thinks they’ll relatively quickly learn things about the product that you don’t know and put it to uses you never anticipated. He’d expect that learning to be as much collective as individual. He’d probably have more emphasis on providing customizable software than is common today, or including a toolkit people can build on. He’d favor tools that support workflows rather than tools that aim to automate them, relegating humans to only the tasks too hard to automate. He would not make business software that forces humans to “work to rule”. Is the point to control people or to make more money? (Yes, the point is often to control people, to support and extend a company’s hierarchical economy. Maybe such software shouldn’t be written.)

Scott would especially warn against distance. What might be the characteristic failure of High Modernism is thinking of users as mere “subjects of the State’s attention”. Quote: “Such subjects - like the ‘unmarked citizens’ of liberal theory - have for the purposes of the planning exercise, no gender, no tastes, no history, no values, no opinions or original ideas, no traditions, and no distinctive personalities to contribute to the enterprise. They have none of the particular, situated, and contextual attributes that one would expect of any population and that we, as a matter of course, always attribute to elites.”

Scott would probably be a big fan of personas and having programmers sit behind one-way mirrors and watch users performing tasks.

Even though this episode is already a bit long, I have one last point to make – some recommended reading for you (that I, I admit, have not done myself yet). I mentioned last episode that Le Corbusier and Lenin are Scott’s main villains. Jane Jacobs, author of /The Death and Life of Great American Cities/, is the hero opposing Le Corbusier. Opposing Lenin is fellow revolutionary Rosa Luxemburg.

I’ll sketch the differences Scott calls out, and provide links to the relevant writing in the show notes.

The villains emphasize formal order from above; the heroes favor informal order, developed by the people on the ground rather than by planners.

The villains use metaphors of machines and factories; the heroes use metaphors of growth, biology, and medicine. (Side note: in the modern financialized economy, our High Modernist metaphors aren’t so much of gritty things like factories but of financial approaches and financial instruments.)

As High Modernists, the villains emphasize the view from above, the God’s-eye view. The heroes emphasize the ground-level view. Jacobs cares about what people see from the street level while going about *all* their daily tasks, not just the ones city planners focused on; Luxemburg cares what factory workers see from the factory floor.

The High Modernist view ignores history and envisions a static solution that, once attained, wouldn’t need to change. The heroes think history matters and expect that there will continue to *be* history and change. There’s no point where the problem is solved once and for all. Put a bit differently, the heroes care about the trip more than the destination, because it’s *in* the trip that you learn more about what the destination ought to be. As Luxemburg says, “the errors made by a truly revolutionary labor movement are historically infinitely more fruitful and valuable than the infallibility of the best of all possible ‘central committees’.”

Finally, the High Modernists want to get ever better at planning, and the heroes want to get ever better at improvisation.

Something to consider as an alternative to Seeing Like a State.

Let me end with one more inspirational quote from Scott:

“If Lenin approached the proletariat as an engineer approached his raw materials, with a view toward shaping them to his purposes, Luxemburg approached the proletariat as a physician would. Like any patient, the proletariat had its own constitution, which limited the kind of interventions that could be made. The physician needed to respect the patient’s constitution and assist according to its potential strengths and weaknesses. Finally, the autonomy and history of the patient would inevitably influence the outcome. The proletariat could not be reshaped from the ground up and fitted neatly into a predetermined design.”

Thank you for listening.