The first and second posts of this inquiry summarised nine different published presentations of permaculture design process. The third post shared a seeming contradiction between permaculture’s emphasis on mimicking nature and the common permaculture practice of completing and only then implementing a detailed design.1
In this fourth post I explore Christopher Alexander’s long-standing contention that this is a real contradiction and furthermore a contradiction that can only be resolved by revisiting and radically revising our most basic understandings of what nature-mimicking design actually is.
I’ll start by looking at a tiny part of Alexander’s career-long critique of the design processes used by conventional architecture (the flip side of his attempt at an alternative). We can consider what (if any) of this applies to permaculture later. But first, let’s consider the validity of his critique in a purely architectural context.
In Book Two of his Nature of Order Series, titled The Process of Creating Life, Alexander (2002) describes in some detail the process used by the famous painter Henri Matisse when creating his works of art. He then goes on to ask:
What is the essential difference between Matisse’s successful process and the unsuccessful process typical of our professional architecture today? Suppose an architect at a large commercial office like Skidmore, Owings and Merrill is drawing their design, and then makes the claim that what they are doing is just like the Matisse process? Can we answer? Is there an objective distinction between the one process and the other?
The critical difference is the absence of feedback. In Matisse’s process, each step is a small step forward from a previously existing reality. The next step is taken as a feedback and as a response to the reality of the actual painting, as it emerges. That is what keeps the thing on track, and what keeps making it better. Matisse is watching the actual painting; his hand is hovering over it. He drops down one more spot of colour, in response to the real thing. Each move he makes is based on the direct feedback from the real thing, and the real feeling as a whole, which the evolving painting creates. The process therefore has a good chance of making the real painting better all the time.
The architect drawing at their table or on their computer is an entirely different case. The architect is drawing the building. But since it is not the real building which is being formed, nor any simulation which might come close to creating feelings and sensations like those which the real building will create in the user’s mind, the architect cannot tell, while they are drawing and from what they draw, what would really be going on in the actual building if it were built. They get no realistic feedback from the drawing on paper because one cannot judge the real behaviour, the nature of the real building, by looking at the lines on paper. Of course, this architect, if challenged on this point, might claim that this is just where their experience lies: that they can tell, from the pencil lines, what the real building would be doing and that it is this ability which makes them an architect. But this is a polite fiction. It is a polite lie on which our 20th-century architecture was based. The truth is that no one can tell what the three dimensional reality of the building is going to be based on a few pencil strokes or a few lines on a computer screen. You cannot tell what the light is like, what the view is like, where the plants will grow, where you feel like walking, where you feel like sitting, what natural intuitive response a group of people will have to sitting in a particular room (if it is too high, too low, too wide, too narrow, too strangely shaped, too distant in feeling from the garden or the room next door), where the sun is going to shine on the floor in winter, whether one can hear sounds from one room to the next, and so on–a thousand things. And it is because of this ignorance about real things that we do not get feedback from the pencil sketch.
That is why what we architects do with our pencil sketches is not in the least like what Matisse did when he painted the Woman in a Chair. At best the architect is drawing something, and their next step is a reaction to the drawing. Each pencil stroke is thus only a reaction to a previous set of pencil strokes. Since it is not, at any step, based on feedback about reality, there is every chance — one might say there is a certainty — that this process is going to go off the rails. It is the lack of continuous responses to reality which makes the process used by big commercial offices highly vulnerable, and which makes it — inevitably — unsuccessful. (p. 245)2
The significance of this passage is made harder to grasp by the fact that in Matisse’s case, the actual thing he is ultimately creating is on paper. The thing the architect is ultimately creating, on the other hand, is out in the world and made of concrete (or mud bricks) and glass etc etc. The question naturally arises, therefore, of “yeah sure but how on earth do you get the real feedback you seek as an architect – are you saying that you must go ahead and start building with no plan? With no design? That is a patently insane recipe for disaster!”
This is a question I’ll come back to in upcoming posts.
But for now, let’s start teasing out the implications of all this for permaculture design.
For a start, we should acknowledge that surely all (or at least most!) permaculture designers are more in touch with the realities of the site than the average architect. Permaculture has always been about tuning deeply into the landscape, and increasingly emphasises tuning deeply into the clients and the goals they articulate.
Yet these truths in no way erase Alexander’s contention that no matter how deeply we initially tune into people and place, if we complete a detailed design on paper (or computer) before implementing it on the ground, we lack the feedback necessary for the design to be particularly good, in the sense of highly adapted and harmonious (akin to nature’s creations).
An obvious retort from a permaculture designer practicing in what we’ve established as the standard permaculture way might be:
yeah we get all that – hence the evaluation or feedback phase during or after the completed design’s implementation
Toby Hemenway said as much in The Permaculture City:
This [evaluation] step is missing from many traditional design processes. Often, architects and designers move onto another by the time one project is done and don’t hear whether their concept actually worked. In permaculture design it’s an integral part of the design process. It creates a feedback loop, a defining hallmark of any whole system (p. 46)
Yet from Alexander’s perspective, this kind of after-the-fact feedback doesn’t cut the mustard. It is too little. It is too late. In the next post, I’ll go deeper into why.
Note: In the meantime, I invite comments3 from anyone who has experienced the process of completing a detailed design then implementing it. How did it work out? Did the lack of real feedback discussed by Alexander in this post create any issues? Was the detailed design a help or a hindrance? Did you have to tweak or adjust your design as the implementation unfolded? Or was it totally fine and you see no issue with such an approach? Do you feel any resonance of any of this stuff with your own experience? Come on people, don’t be shy, say something – let’s crack this conversation open together!
References
Alexander, Christopher. The Nature of Order: An Essay on the Art of Building and the Nature of the Universe: Book Two: The Process of Creating Life. Vol. 2. of 4 vols. The Center for Environmental Structure, 2002.
Hemenway, Toby. The Permaculture City. Chelsea Green, 2015.
Another programmer here chiming in – a common theme eh?
I definitely see and have experienced both sides of this argument.
In instances I absolutely had to have a design ahead of time to even get a grasp of the “whole” project. In this case I am thinking of a series of earthworks I did a recent install on. If I had just jumped in I really do think it would have been a mess.
However, while the design did help get things going in the the right direction (especially with something more on the permanent side such as earthworks), it was not as good as it could have been. The feedback loop showed issues, weaknesses in my my design that my eyes did not pick up on during the process of observing and translating that to designs.
In other instances I just ran with what I wanted to (on a whim) without a design, starting smaller and making adjustments as I go. Sometimes this worked out well other times it meant major issues. In one instance I built a 250 sq ft shed 90% complete and decided it was in the wrong spot for the site. Took it apart and pulled it about 600 feet down the hill to a new location.
Such experiences leave me seeing how us humans do not work as nature does but can benefit from her methodologies. Her unfolding is based off a pattern that failed or succeeded over millions of years developing a refined pattern that often produces the most efficient and beneficial outcome.
How us humans can condense this down into a lifetime, or better yet, a few years to design and develop a homestead is where I leave off with questions.
I see how permaculture designs that I do are my best attempt yet in the larger picture still half baked. Every design that is executed leads to more experience and knowledge to better inform the next. I suppose this is in fact mimicking mother natures long term process of natural selection in a way.
Struggles of being a human trying to mimic and understand nature aside, I remain open to learn from her and improve / refine the permaculture practice.
Hey thanks for sharing Bret! These kinds of real-life examples (grit and all) are just invaluable, and your humility is encouraging (and sometimes a sorely missing ingredient in permaculture design examples where the grit tends to get ironed out in the retelling ;-)). Your comment nicely captures the desire for any appropriate design process to both avoid rushing in and making big mistakes due to a lack of appropriate planning (moving large sheds is hard work!) as well as being adaptive / real feedback rich enough so as to not have the opposite kind of mistakes happen – where the loud voice of a pre-formed plan shouts (or bulldozes) so loud that the whispers of what’s actually happening on the ground don’t get heard and responded to. I sure don’t have the answer but I do look forward in a few posts time to sharing some real-life attempts at finding the sweet spot where what happened was, at the least, a huge improvement over the more standard approach I’ve taken in many hundreds of previous design projects (and don’t get me started on the grit therein!).
I’m a software developer by day (permaculture designer wannabe on the weekends), and a lot of what you said resonates strongly with me. Over the past few decades, the software development world went through a similar set of discoveries — ‘Big Design Up Front’ (BDUF) didn’t work well because (a) it assumed too much about the client’s needs, (b) it wasn’t capable of changing its course quickly if client needs changed, and (c) it assumed that the expressed needs of the client truly were the real needs of the client.
Nowadays the darling software development methodology is called ‘Agile development’, expressed most succinctly in the Agile Manifesto http://agilemanifesto.org/ Design and implementation cycles happen regularly (typically somewhere between weekly and monthly), and the goal of each cycle is working software that meets real client needs. (Any given iteration might add anything from a few accounting-related functions that spit out the correct answers, up to a new user interface element that solves a recently discovered pain point for customers.)
The emphasis is on relationships with the client, solving the right problems, small iterations with tight feedback loops, nimble decision-making, and demonstrable results. Sound familiar? Sounds a bit like “integrate rather than segregate”, “articulate goals accurately”, “apply self-regulation and accept feedback”, “creatively use and respond to change”, and “obtain a yield”.
The early proponents of Agile were also big fans of Alexander; there are many pattern libraries available for programmers who don’t want to re-solve solved problems. They tend to be articulated in similar ways to Alexander’s patterns: state the problem, give a label to the pattern that solves the problem, then describe (in a general way that’s not tied to any programming language or architectural methodology) the ‘recipe’ of the pattern.
One mismatch that I see between agile software dev and permaculture is that agile typically just starts working on details and expects a cohesive design to emerge, whereas with permaculture we try to get the big design right to avoid any foundational errors. This is a bit of a caricature, I guess; a good agile developer is always thinking about patterns and overall architecture as they build individual elements. Still, it’s definitely a detail-to-pattern approach. Nevertheless, it tends to work quite well. An interesting side thought from a discipline which looks quite different on the surface but is actually quite similar.
One aspect of agile development that I find hard to relate to permaculture design is that there’s a strong emphasis on
Hm, it cut off my comment. What I was going to say is that with Agile, there’s a strong emphasis on getting into the details first and treating the design as an emergent property. Whereas in permaculture we talk a lot about working from pattern to detail, getting the basics right to avoid foundational errors. I’m caricaturing Agile a bit; any good Agile developer is always thinking about patterns (see above re: Alexander and software pattern libraries) and the overall architecture as they build individual elements.
Still, the emphasis is on building and connecting individual, self-contained elements. Despite the apparent lack of up-front design, this works surprisingly well, because (as the Agile axiom goes) you never know what you’re supposed to be building until you start building it. I think another reason it works so well is because of another Agile axiom: refactor (tweak/modify/rearchitect) mercilessly as your project grows.
Anyhow, just an interesting side thought from a discipline that seems unconnected but actually shares a lot with permaculture.
Oh, apparently it didn’t cut my original comment off; I just left an unedited bit at the end. Ha! I feel like my second try was better anyway.
Hey Paul and thanks so much for commenting! Hopefully others will follow your fine example ;-). I’m excited to read your rich reflections on agile and some of the synergies and dissonances with permaculture. I dipped into agile a few weeks back as part of research for this inquiry and was quite amazed at its relevance. I plan to share and develop some of those dippings in a few post’s time, which will now be enriched by weaving your reflections in, and, I hope, having your input again at that stage (ooooh – this inquiry is itself getting a little taste of agile goin’ on!). What fascinates me is that software development confronted and traced the implications of this stuff out (as you say with a little help from Mr Alexander – you stole my thunder there but all good, I can share ;-)) long ago, yet as you hint in your reply to Rutger the way it rolls out for permaculture will be different even if stemming from the same realisation – BDUF just ain’t cool.
ps. You mightn’t have noticed but coincidentally the url http://www.agilepermaculture.com was also registered a few weeks back. Fancy that!
Alexander(*) might note that the detail too holds information on patterns through recursiveness and the nesting of layers. In that case there is no contradiction whether starting out with the detail or the whole. The principles (or values) that guide the consecutive unfolding of the following steps is what is important.
* http://www.katarxis3.com/SCIENTIFIC%20INTRODUCTION.pdf
As for the discussion on architects versus Matisse, I would rather state that architects are merely the canvas frame builders on which the life that takes on inside it is the ever changing paint. And yes – there are indeed weak and stronger canvas builders. Good building are open to change (embedded robustness & resilience) and bad buildings are simply torn down. That is why often old buildings, the survivors of this process of selection, are so loved.
As for designing by doing or by premeditation (‘drawing board”) I know from experience you really need both. It’s the issue of complicated versus complex: components level versus system level. It’s wise on component level to at least design an infra structure or set of governing rules (or you wast a lot of resources fixing conflicts). As for designing on the system level, I believe more and more people are slowly becoming aware how buildings fit into the larger system and what this implicates for the design.
Hey Gerald and I love your comments! Only thing I’m not sure about is the word “merely” in that assumptions and decisions go into the making of any canvas that direct / constrain /shape what is possible come painting time and often tearing a building down only happens after many years of unnecessarily compromised living. But as you say that’s why it’s important to be able to distinguish between weak and strong canvas builders! I really like Stuart Brand’s How Buildings Learn work on this topic. In one episode of the documentary series he made after the book he looks at a project of Alexander’s and points out that there not only is the building able to change/evolves once built, but the process of building it is wide open to change in a degree unusual for modern architecture (due to the way that premeditation and doing are intertwined).
I’d love to explore your first paragraph more some time (it is a pocket of densely concentrated insight!) and your last paragraph is awesome and super relevant to where this is heading – I suspect I’ll be quoting you in due course.
Thanks again for chiming in.
Hi Paul,
I’m a programmer too, and noticed some similar relationships between Pc design and Computer Science stuff. The main realisation for me is that design is searching through a space of possible solutions for something that’s reasonably optimal, so a lot of CS heuristics (particularly search, etc.) apply. I wrote up some of it here: http://neoluddic.tumblr.com/post/150212503801/permaculture-patterns
I would probably add that BDUF still works, it’s just suited to problems which you can nail down well, examples being space probes, car and plane software or life-critical things like medical equipment. I’m not sure how you’d get something like that in a Permaculture design – some sort of factory-style aquaponic or hydroponic system perhaps?
Hey Anthony and your comment reminds me I never got back to you about your thoughtful blog post as I intended to! Apologies and I have now at least added a link to it here though, and details (or elements) aside I love the idea of design process as a whittling down of solution space. It would be great to have a post exploring this more in future and I’ll actually think about working it into the current inquiry. Also that’s a good point about how BDUF is more appropriate in some domains than others.
Anthony, I thoroughly enjoyed your blog post. It’s a fabulous contribution to the discussion, and judging by its publication date, you’ve been thinking about this for a while already. You echoed my feelings about element analysis, plus my frustration that permaculture doesn’t have a go-to pattern library like architecture and computer science do. Some resources do (the Big Black Book comes to mind, although most of its patterns seem to be appropriate for broad-acre and/or hot-climate applications).
Re: BDUF sometimes working, I’d add that sometimes Agile fails miserably. If the culture of your company or the clients is too brittle or bound up in politics, agile processes will be constantly hindered. If your client isn’t highly knowledgeable about their needs and how software might help them, and if they aren’t willing to take part in the decision-making, the project can turn into a mess in short order.
Completing a detailed design and then implementing it is not ideal in my experience. But in architecture there is no other option, at least where I live (Netherlands) because you need a building permit. And to get a permit you need a detailed design. There is hardly any space for change during the construction stage.
In permaculture we often have the luxury to keep on adjusting and tinkering. In all my permaculture projects we have made changes during the implementation. In reality you see things differently. And when you start using it perception changes again. Some things don’t work out as planned and need to be adjusted but you also see new possibilities. A design is never finished.
Thanks for your investigation of the design process. I’m looking forward to your next posts.
Legislation isn’t the only problem I see with doing iterative, constantly changing designs using the actual medium you’re implementing in. I have a hard time figuring out how to make this happen at all with architecture (would you tear down a wall and rebuild it slightly differently based on the feedback loops of usage patterns after a few years?) Dan promised he’s going to unpack that sort of problem in a future post; I’m looking forward to it eagerly!
Thanks Rutger and again to you Paul,
In a future post in this inquiry, after fleshing out and discussing the ideas a bit more, then sharing a few applications to a couple of real design projects, I plan to dedicate a post to exploring the issues and challenges a more agile, acorn-like approach presents, including the fact that an up-front detailed design is so often a legal requirement! You actually get penalised for trying to buck the BDUF! Another very common question I get is how do you make such an approach pay as a professional consultant. Anyway, we’ll get to such matters in due course, after having gotten clearer about ‘all the fuss’ is about.
Rutger your statement “In permaculture we often have the luxury to keep on adjusting and tinkering. In all my permaculture projects we have made changes during the implementation. In reality you see things differently. And when you start using it perception changes again. Some things don’t work out as planned and need to be adjusted but you also see new possibilities. A design is never finished.” really resonates. That said, I wonder if there has ever been a permaculture project where the implementers stuck to the initial plan, no matter what – surely a sure-fire recipe for project failure or at the very least a sub-par outcome…