On the Relation between Designing and Implementing in Permaculture – Commentary from Anthony Briggs (Inquiry 2, Post 25)

Note from Dan: In this post Anthony Briggs from Melbourne shares his reflections on Making Permaculture Stronger, the current inquiry and in particular an alternative take on generating processes.

I’ve been reading Making Permaculture Stronger avidly since Dan first started writing it, about his reactions to the limitations of Permaculture’s big upfront design process, and how he and others have improved it by splicing in Alan Savory’s Holistic Management techniques and Christopher Alexander’s Pattern Language and holistic methods.

I watched a similar process play out in my field more than a decade ago. Around the mid-1990s, people started to realise that the standard software development process (usually some variant of waterfall) was pretty broken. Knowing enough detail upfront to be able to plan a successful project from beginning to end has a large cost; in complex, changing situations, mapping out every detail quickly becomes exorbitant. In response, systems like Scrum, Extreme Programming and Lean Software Development were developed, under a broad “Agile Development” banner.¹

All of which maps onto Dan’s Permaculture design spectrum pretty well.² Waterfall is the dreaded Big Design Up Front, aka. Fabrication, and most of the agile programming systems above fall pretty squarely under the Generating or Hybrid models that Dan’s described. All of them use rapid iterative cycles, deliver a small amount of stuff at a time, and accept feedback, and frequently use low-detail-but-good-enough documentation like user stories and burndown charts to get things done.

But of course, like any two human beings, Dan and I have differing opinions on some of the things he’s said here, despite agreeing on 95% of it, and so he’s suggested that I put down some of them in an article. There are also some of his ideas that I can extend or put a different spin on.

Design and Computer Science

The first cross-pollination was when I realised the overlap between some of the Permaculture design methods and Computer Science (CS).³ There’s an old adage about CS being about computers in the same way that Astronomy is about telescopes – they’re useful tools, but ultimately not what the field is about.

My favourite definition of CS is this one:

Computer Science is the study of the storage, transformation and transfer of information. The field encompasses both the theoretical study of algorithms, and the practical problems of implementing them in terms of computer software and hardware.⁴

If you think of design at a high level as being a search for a solution (or even just for information) given a particular set of resources, constraints, people and places (the context), then there’s a lot of CS that’s directly relevant: organising what you know and making connections between the parts, searching through that information, and then making sense of the knowledge and its connections and mapping that back onto reality.

A working definition of design that emphasises this might be something like:

The search for a workable solution to a problem in a highly complex situation.

If you’re doing something simple like making a sandwich or switching on a light there’s not much design needed, but as the complexity of your task goes up there’s more need for a structure to manage the information and communicate it as you search for a solution. Structure covers things like processes, algorithms, check lists and design documents but also more fundamental things: connections, hierarchies, trees and networks.⁵

Fabricating

Dan paints Fabricating as a terrible, horrible, awful thing to inflict on people,⁶ and it is a bad choice for most Permaculture projects. But depending on the situation it can be a better choice than a generating process:

• If you have a high cost of failure – due to safety or financial concerns.
• Your project is deployed into a very predictable situation.
• If there are time constraints and you can’t iterate, or you only have one chance to get things right.

Sometimes this means that you have to reduce the scope of the project to just what you can accurately predict or model, or run a very specific process to make sure that things are predictable. Think of the programs running medical equipment, airplanes, cars, space probes, power plants, phone networks, banks, and so on.⁷

Most Permaculture projects are relatively small scale, but I can think of a few cases that might fit the bill. If you wanted to design an ecovillage or small town, you’d want to spend time making sure that you have enough water and food for everyone. If you were to run it in an agile way, you’d add people until your limits on water were reached. In Australia we have dry spells every decade or so. An agile village may start up during the good years, and grow rapidly, but then end up having to kick people out at huge personal cost when conditions change.

It’s much better in that case to map out better to map out the climate, soil types and rainfall patterns ahead of time than “just build the dam a bit bigger if you need to”. Permaculture tends to favour small and slow solutions, but sometimes you don’t have a choice.

If you’re interested in exploring these themes in more detail, then Simon Wardley has done a lot of writing on the process he uses in mapping high level IT project landscapes, and deciding which technologies and project management styles to use. A good starting point is his article Better for Less, particularly figures 235 and 236.

Continuous scale, rather than four process types

One of the tenets of Agile processes is that you should modify your process where it makes sense. You might need some extra steps around a risky task like updating a server, or you might be able to drop something (like a meeting) that doesn’t make sense. There’s a balance between how much time and money you spend upfront, and the risk that something will go wrong, and you can spend more effort if you need more control.

So I don’t really see four separate types of development as Dan’s mapped out (and Dan’s mentioned “continuum” and “hybrid” several times, so I know he doesn’t either).

Instead, there’s a more continuous scale of “How much control (or pre-knowledge, understanding or certainty) are you trying to get over the thing that you’re designing for?” One end is “lots of control”, and the other is “no control at all”. One more document or design meeting won’t tip you all the way into Big Design Up Front, but maybe just an extra 1/17th of the way.

The important point though, is that you can modify your process (more or less up front design work) based on how much information you have, or control that you want. It’s also one of the reasons that I think “Winging It” should be on the right hand side of Dan’s chart: it makes the gradient of control much clearer.

I can imagine a hybrid between any of these four types of design, except for Winging It and Fabricating.

As an example, if you’re in a situation where you don’t know enough about your current context, then it’s difficult to come up with a design until you do. So a hybrid between Winging It and Generating works: Try some things out until you can see the patterns, then fit your observations (and current “design”) into a generative process. Processes like the Lean Startup model tend to work this way – come up with a “pie-in-the-sky” business model, write down the assumptions that it’s based on, then demonstrate or invalidate them as cheaply as possible.

And sometimes, yes, once you’ve figured things out, you find that what you’ve been doing is completely wrong, and the best option is to throw away what you’ve done so far and start over with something more appropriate. You might have quite a bit of time, money or ego invested in the existing design, but it’s a sunk cost – in the long term the better design will win.⁸

Actual control

But the control that you’re trying to assert is a two-edged sword – it’s only *attempted* control. The more chaotic the situation, the less well your control works, and the return on investment of your planning starts to diminish. A detailed design or program specification in thick, three-ring binders isn’t going to help if the whole business model is likely to change, and most of the money and time you spent developing it will be wasted.

Though unlikely to happen in reality, if a situation is genuinely completely random,⁹ then any plan is as good as another, so the best option is to spend no time or effort planning at all, aka. our old friend “Winging It”.

Sometimes too, the situation changes. It might become more or less chaotic ¹⁰, and so the best methods to use change too. Better technology¹¹ can help too, by making design cheaper or less risky. A good example is drone mapping. 50 years ago a 50cm contour map over 100 acres would’ve been too expensive to worry about, but now it’s doable with a drone for only a few thousand dollars. With better, more detailed information available, you can improve your control over the project, and make a more detailed, predictable plan for less cost.

Large -> Small patterns

As an extension to one of Dan’s diagrams, I’ve noticed that the “decide-draw-do-decide-draw-do-decide-draw-do” charts are not the whole picture. Dan also uses the Yeoman’s Scale of Permanence in guiding what to work on first. Similarly, when Dan talks about how Bill Mollison set out hybrid designs, Bill starts with large scale up front plans, then works out the smaller details as he goes.

So, the “decide-draw-do” diagrams would more properly look something like this.

Impact grows smaller as you progress through and complete a design. Choosing your site will have the largest impact, adding water and access a smaller (but still large) one, crops and animals a smaller impact still, and so on.

In an ideal design and implementation, the impact of designing and doing is large to start with, but then tapers off as you “fill in the gaps”. If you reach an impasse and need to step back and fix parts, then the impact will jump high, then taper off again.

Dan’s techniques and “Qualitative” design

Where I think Dan’s having the biggest impact is in adapting Christopher Alexander’s process to Permaculture, and fully exploring how a design might “feel” when it’s implemented and you’re in it. Our culture trains our analytical conscious mind to override these feelings, so you might not even notice them – but in the long term they have the most impact.

Dan frequently refers to “tuning in” to a situation or context, or “immersing” yourself – slowing down and taking time to see how a particular place or element of a design makes you feel. Hot? Cold? Windy? On edge? Exposed or isolated? Too close or confined? Enclosed in a nest or sanctuary? Worried about whether you’ll have enough water next summer? Dan’s design process starts with the feelings that are the strongest, which I think is hugely powerful.

I’ve been thinking of this perspective as “Qualitative Design”, as opposed to the normal“Quantitative Design” view, which mostly focuses on easy to measure yields like “How much food can I get out of this patch of land?” or “How long does it take me to do my chores each morning?” If we want to change Western culture, and we desperately need to, this (I feel) is the place to start. Another way to think about it might be as “Inner Landscape Reading”; the human-centred dual of David Homgren’s physical landscape reading.

What does this look like with a person in the middle?

As a hard core reductionist scientist type person, this was a key realisation for me on the last day of the Advanced Design Course with Dan and David – that the aesthetics of how elements are arranged (or differentiated) and how they interact with the people involved should be an integral part of the design process. People are the biggest component of a design, so it makes sense that one which facilitates happy, productive people will give much better results than just optimising yields and drawing straight line efficient paths between parts of a site..

In a comment on an early draft of this piece, Dan describes his process as:

…in a generating attitude MORE time and effort goes into upfront mapping, listening, immersing, tuning in, calculating, researching etc (not to mention honing in on and crash-testing first steps). As in much, much more, such that what actually happens is much more deeply a reflection of the real forces at play in the situation. The focus is on getting the next step right […] a generating approach is more closely focused on letting the details change as proves optimal for the context as the actual dam is being built.

…which seems pretty bang on to me in context with everything that I’ve seen Dan and VEG do. Ironically though, by taking more time and mapping out everything to do with the next step, Dan’s moving back towards what seems to be a more deliberate, Fabrication side of the scale, albeit Fabrication after trying to absorb as much information as possible, including via subliminal impressions. Perhaps this is a sign that there are two parts to the Living Design Process that might need to be differentiated: the iterative process, and the “tuning in”.

But that’s just me being contrary again, I can’t help myself.¹² It’s been amazing to take both a PDC and and Advanced PDC with Dan, as well as following Making Permaculture Stronger, and watch him evolve these thoughts and put them into practice, and I’m looking forward to seeing what he comes up with next.

Endnotes

1. There are differences between these methods, but overall they’re outweighed by the similarities.
2. Which is great, by the way. I don’t think you should take any abstract concept too seriously until it’s turned up in at least three independent fields.
3. I wrote a bit about that realisation and pattern languages here
4. linfo.org/computer_science.html
5. A couple of good examples: Simulated Annealing (https://en.wikipedia.org/wiki/Simulated_annealing), where you have a complex function to minimise, and approximate a minimum via “progressive fiddling with your solution”, and Decision Trees (https://en.wikipedia.org/wiki/Decision_tree_model), where you lay out all of your possible decisions, their dependencies and outcomes as a tree so you can think about it clearly.
6. He doesn’t strictly speaking say exactly this, but in Part 5, Dan says things like:
   * “the process of completing a detailed design before implementing it (fabricating) is inherently flawed”,
   * “if you are making your design decisions based on what you’ve just drawn, you just don’t have access to enough key information to avoid making a shitload of mistakes”
   * and uses a quote from Christopher Alexander: “A fabricated plan cannot avoid mistakes, and in all fabricated plans, the overwhelming majority of possible mistakes, are actually committed”
7. They write the right stuff: https://www.fastcompany.com/28121/they-write-right-stuff
8. Extreme Programming has a tactic called a “spike solution” that tries to counteract this tendency. Where you’re uncertain of an aspect of your design, try a low-investment test implementation, with the intention of throwing it away once you’ve answered your question. In a Permaculture context, this might be something like digging and filling test holes for a dam, or choosing a house site by setting up a yurt and living there for a while.
9. If it helps, perhaps imagine a fairy curses you to wake up each morning on a different farm, with completely different crops, animals, climate, etc.
10. Think about climate change, particularly in an Australian context. “Droughts and flooding rains”…
11. And by technology, I’m including thought processes and information too – anything that people invent, including Dan’s design process.
12. If you want to work out the size of a field, it’s easier to do it from the fenceline, not safely in the middle ;)