Advanced Permaculture Planning and Design Process 2017 – Part One: How it came about

This post commences a little intermission from the current inquiry. For, while it is fresh, I’ll pen a report of the four-day Advanced Permaculture Planning and Design Process workshop David Holmgren and I recently co-presented. I’ll cover the experience with a post for each of six parts: how it came about, the four days of preparation directly before, and then each of the 1, 2, 3, 4 days of the event itself.

First though, if you’ve not the time or interest to read the full report,1 here’s a short clip of David and I sharing some post-course reflections:

Part One: How it Came to Pass

Not long after Making Permaculture Stronger started, I sent a draft version of this previous post to David, hoping for his feedback. To my delight, a lively email conversation ensued, excerpts of which were posted here. Details aside, I was grateful for David’s interest and participation in a conversation following and building on my earlier claim that design process is a problematically weak link in permaculture.2

During the decade or so in which David grew from acquaintance then teacher into the mentor, senior colleague, and friend he is today, we had never really discussed permaculture design process. I’d been fortunate enough to observe David in process on several rural properties over the years, where I got to read him reading landscape, but we hadn’t much talked about what was going on.

After that email conversation, however, things had shifted. The topic was on both of our radars as a shared interest. Though we enjoyed several face-to-face chats, which for me put some rather deep scratches in the surface of the topic, I was left with the feeling of wanting to break right through the surface, to dive in deep, and see what we found. Of wanting Making Permaculture Stronger to further benefit from David’s 40 years of grounded experience and deep thinking about permaculture design.3

Now if anyone had approached me at this point and said “well why don’t you just ask David whether he’d be up for an eight-day full-time intensive discussion going deep into all this stuff?” I would have laughed. Something like that simply wouldn’t have occurred to me as being within the realms of possibility. David leads a full life and I knew was busy working on getting his latest book project across the line, re-tweaking an upcoming re-release of his permaculture principles, co-managing Melliodora, and so on and so forth. I was more than grateful for the shorter conversations we were able to have, and hoped/trusted our conversation would continue to evolve slowly and opportunistically in small increments over the coming years.

You can imagine, therefore, how low my jaw dropped when in late September 2016, David asked whether I’d be interested in co-facilitating a four-day “advanced permaculture principle and planning” workshop during April of 2017.4

Though I tried to play it cool – “yeah thanks for the thought, let me think about it” sort of thing, my decision to accept the invitation took about three seconds. I was excited at the prospect of an opportunity to co-evolve some of this stuff together, knowing from past experience that co-teaching is about as good as such opportunities get.

I learned after the event that David, though excited, was also somewhat nervous about how it might play out. As he put it in the post-event video I shared above:

I thought going into it the uncertainties of unpacking so many things that I’ve been uncertain about in permaculture design, and the first time directly collaborating on something like this with you, and building on all the stuff you’ve been doing on the making permaculture stronger blog, I was really excited but nervous about how it was going to work and whether we were going to get into runaway, abstract, philosophical discussions that would leave the students, even the more advanced ones, struggling.

From my end, I was telling myself not to set my expectations for the course too high. I know from experience that such events often don’t turn out quite as magnificent as the picture my mind tends to paint in the lead up. I was also conscious that we had no idea who would show up, and how it would work to be exploring the depths of permaculture design process with a bunch of, well, goodness knows who. I also really wasn’t sure to what extent David’s and my own design process understandings would actually gel or complement each other. Finally, I knew David had a relatively well-rehearsed and refined program from his past advanced principles and reading landscape workshops and I half-expected I would end up simply sort of tacking on some of my stuff around that.

So much for expectations!

In the next post I’ll go through the process of preparing for the event.


On the Relation between Designing and Implementing in Permaculture – Part 10

I said in the last post that this next post would start sharing an example of permaculture design in the CDUFDDAYG (concept design up front then detailed design emerges as you go) mode.

As it turns out, this post constitutes a slight deviation1 from that plan. Here’s why:

In starting that post I quickly realised there was an important omission in the below diagram that was important enough to need its own post to rectify.

I invite you (yes – YOU! YOU RIGHT THERE!) to consider this diagram and think on what forth category might be missing – what I consider one of the most culturally dominant approaches to creating stuff (alongside CDDUF). Here is a little blank thinking space for you…





[STOP & insert your thinking here]





[scroll down when you’re done…]


Okay so what I realised is missing is the very common pattern in which you start implementing haphazardly where only chaos, mistakes and dead ends emerge as you go. Further, I realised that this omission could create great confusion in that this chaos mode, which reliably fails to create meaningful order, would be confused with CDDAYG, where the point is that the process is conducted in such a fashion that meaningful order does emerge, and major mistakes and backtracks are successfully avoided (as I’ll explore and even demonstrate in due course).

Anyways, whilst I continue taking my sweet time in preparing what was originally for this post, I’d love your feedback on this latest iteration of the diagram:

Note that this fourth category differs from the first three in that all three of them, it might be said, involve some kind of intentional design approach, however premature (CDDUF), or, conversely, seat-of-the-pants (CDDAYG). RIGNCD, on the other hand, involves no or at most very superficial or tokenistic attention to any kind of design process at all. Hence the dashed line demarcating the new category from the prior three. Here we are pretty much leaving the domain of design altogether to run around in circles digging holes faster than we can fill them in again (when we belatedly find out they were in the wrong place).

I don’t know about you, but I immediately find this addition helpful in making sense of creation processes used in modern culture. For example, much modern apartment development is a combination of mistake-ridden CDDUF (up front image-driven architectural master planning) within each project and effectively RIGNCD across projects. Hyper-imposed, premature and ultimately dysfunctional order in the small, yet random, haphazard, and ultimately equally dysfunctional dis-order in the large.

And so on. Anyway this is a quick draft so please share your thoughts and let’s make it better together. Oh yes, I’d also love to hear if anyone has example suggestions for the spaces I’ve put question marks.

Update (April 24, 2017)

Further to the above, based on the wonderfully helpful comments from James, Bret, Mark, Milton, Alexander and Jason,2 here is a revised version of the above diagram with quite a few new layers to it (see below or get as PDF here). I only have a moment right now, so am simply sharing the new diagram without explanation, and will add some explanation within a week or so (as well as responding to each comment individually – hopefully it is clear that every single comment has had an influence). Yet I and trust/hope it is fairly self-explanatory?

Meantime let me share my gratitude for your comments. It excites me to be getting to a place with this project where folk from around the world are feeding into ideas that are unfolding in realtime and where even I don’t know exactly what will happen next. This is also the first time that reader comments (including face-to-face discussions about this with Mark and James) have fed back into the post they were about rather than only feeding forward into future posts. Feels like a healthy step to me.


On the Relation between Designing and Implementing in Permaculture – Part 9

I don’t know about you, but I’m itching for some action.

Don’t get me wrong. It’s been a great ride so far – a real trip! We’ve:

Most recently we dipped into the Agile software development methodology resulting in some crazy rich insights, discussion and brain-stretching in the reader commentaries (such as here or here) along the way.1

Yet the fact remains. I’m itching for some action.

Accordingly, in the very next post I’ll start sharing a real land-based permaculture design process explicitly guided by a CDUFDDAYG approach (completing a concept design up front and then letting the detailed design emerge as you go – see here for a fuller explanation).

The first phases of this process oughtn’t raise any permaculture eyebrows.2 Sure, it has its quirks, but, as you’d expect, it tunes into people and place before unfolding a concept design. No surprises there.

Only at this point do eyebrows potentially start raising. For as you’ll see, earthworks begin without any detailed design drawings. The details were designed in realtime inside the process of their implementation.

This goes directly against the grain of what we have seen is the standard recommendation for how permaculture design ought to be done.3

It is an experiment in a design approach more agile, real feedback rich, and generating (or generative) than what in permaculture has, once again, become standard practice.4

Disclaimer and Condition

What you are about see is an experiment. It is an exploratory attempt to crash-test some of the ideas being here explored.

I in no way wish to convey or leave open any interpretation that I consider this example best-practice, or perfect, or something anyone should unquestioningly replicate. Indeed, feedback on where this process failed or could have been better is extremely welcome!

On the other hand, this experiment (and even more so for the example after that) do constitute the beginnings of what for me has been an exciting new chapter in my career as a professional designer, and if there is anything that resonates then by all means go ahead and test it out in your own world/work, on one condition: that you get in touch afterwards (or before and during, if you prefer) and let me know how it goes.

The more people out there experimenting with this stuff and feeding the results of their experimentation back into some kind of collaborative conversation (wherever that may be), the better. Such conversations are surely a critical ingredient of a permaculture becoming ever stronger.

One Other Key Aspect Worth Mentioning

Although it is the relationship between design and implementation that I will be emphasising in coming posts, there are other non-conventional ingredients in the mix too.  I will touch on these other aspects sufficiently to provide enough context for you to understand the process as a whole, but my core intent is to clearly communicate the way designing was related to implementing as a stimulant of further discussions and developments.

That said, I ought to mention one other particularly significant difference with conventional or standard treatments of permaculture design. In both the experimental processes I am about to share, as per the outcomes of my previous inquiry (which started here and ended here), design is understood as a process of progressively differentiating a pre-existing whole as opposed to assembling pre-existing elements into a whole.5 Now I’m not going to go on about it – I’ve said my piece on this previously – But I just wanted to let you know it is part of the mix.

Time to Get on with it

This post has been a segue. Its job has been to pick up this inquiry and fling it over the threshold between theory and practice. Consider it flung.  Let’s get on with it.


On the Relation between Designing and Implementing in Permaculture – Part 8

Welcome back to the next instalment in this inquiry into the relation between designing and implementing in permaculture design. We are now up to post 1, 2, 3, 4, 5, 6, 7, 8! I don’t know about you, but for me it’s been a fascinating journey with some unexpected twists and turns.

Speaking of twists and turns, in the last post I zoomed way out and up from permaculture to consider design process discussions in general. There, starting from the wickipedia design entry, I followed my nose to something called the Agile approach.

The Agile Approach

From what I can gather, the Agile approach is the pointy end of the action-centric stick we discussed in the previous post.

It is an approach to software development that in less than two decades appears to have revolutionised its field. Agile is apparently now used by more software developers than any other approach. There are hundreds upon hundreds of books about it, and it is being rolled out into business management, project management, process managementmarketing, naval ship deploymentweddingsfamily life (for better or worse!) and much else.

In short, it’s a thing.

So what kind of a thing is it?

While this is the best introduction I have found online, I’m delighted to hand this next bit over to someone who can speak both permaculture and agile. Paul d’Aoust, who in a recent comment explained:

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)1 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 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”.

See also this further comment from Paul, this note from Ethan Roland of Appleseed Permaculture and additional mentions of Agile-Permaculture affinities here and here and here and here.

So where does this land the agile approach in terms of the categories I developed in the post before last? Here they are again:2

As Paul says, a foundational principle of agile is breaking tradition with up-front design and getting implementation into the design process as early as possible. So Agile is by definition anti-CDDUF. But there are two remaining places it might sit. This further note from Paul helps us locate which:

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.

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.

Clearly Agile belongs if anywhere in the CDDAYG (concept and detailed design emerges as you go) camp. Indeed, taking Paul’s above comment on board it is almost like a new sub-category DCDAYG (let detailed then concept design emerge as you go) might be a better fit. But let’s not get too carried away here with such details (or concepts). I’m putting Agile down as CDDAYG.

So, coming back to the thread of this inquiry as a whole, it is interesting to reflect that:

  • Permaculture design process is presented by the permaculture literature in general as all about the big CDDUF (completing a concept and detailed design before implementing)
  • Leading permaculture design process practitioners and writers on a closer look are actually are more about CDUFDDAYG (concept design up front then detailed design emerges as you go – e.g., Bill Mollison, Dave Jacke) sometimes also edging into CDDAYG (concept and detailed design emerges as you go – e.g., David Holmgren, Ben Falk), where, as Paul put it, “with permaculture we try to get the big design right to avoid any foundational errors.” It seems to me likely that over time that permaculture’s centre of gravity will drift in this direction (though a lot of work is still required to clarify the details).
  • Christopher Alexander and the wildly popular, influential, and fast-growing Agile approach are over in CDDAYG.

A Key Difference Between Developing Software and Developing a Landscape

I want to emphasise a key difference between software development and landscape development: the relative reversibility of implemented decisions.

My friend Tom Sparrey has put it this way:

Agile works so well in software because you’re dealing with digital elements, easily rolled back or altered if there’s a functionality problem or bug, whereas in the physical world if you make a big change (i.e. a $10,000 new driveway), you want to make sure you’ve considered it thoroughly (plenty of immersing/emerging) before making a move.

I will come back to this matter in subsequent posts. In particular, I will be exploring this question: does this relative irreversibility in changing the physical (as opposed to a virtual) landscape require a whole-site concept design up front? Or is there some way of safely entering the realms of CDDAYG short of this? Thankfully this is an empirical question and so I’ll be testing it empirically, in the context of a full-scale permaculture property design and development project.3

The Plot Thickens

The day I started writing this post maybe a month or so ago, I was emailed by Takeshi Kakeda4 who is not only a Japanese student of both permaculture and the work of Christopher Alexander5 but a software development consultant.

Naturally, in my reply, I mentioned that I was at that moment researching the Agile movement in software design. He replied explaining that a well known instance of agile called extreme programming (or XP)6 was hugely influenced and informed by the work of none other than Christopher Alexander! Takeshi went on to say that:

Software people paid attention to Alexander’s work, and have been interchanging since the 20th century.7

A few weeks later Paul commented that:

The early proponents of Agile were also big fans of Alexander8

Then Lilian Ricaud added this comment:

Like Paul d’Aoust I emphasize there is a strong link between what you described and the methodologies used by agile practitioners (Ward Cunningham was strongly influenced by Christopher Alexander) and design thinking methodologies.

Reminding me of his interesting essay Permaculture patterning: a design framework for systemic transformation (2015) in which he wrote:

Indeed, in the last few years new schools of thought have emerged in the design field. Pioneered by developers seeking to improve their ability to deal with complex software building projects, agile methodologies embed in their process several principles common to pattern languages and per- maculture approach: (iterative steps, structure- preserving unfolding, adaptive instead of predic- tive approach, use of feedback…). Interestingly Ward Cunningham, inventor of the wiki and one of the main actors of the extreme program- ming methodology and the Agile Manifesto was directly influenced by Alexander (p. 202)

Following up these comments, I found this on Christopher Alexander’s wikipedia page:

In the field of software, Alexander is regarded as the father of the pattern language movement. The first wiki – the technology behind Wikipedia – led directly from Alexander’s work, according to its creator, Ward Cunningham. Alexander’s work has also influenced the development of agile software development and Scrum (From the Wikipedia entry on Christopher Alexander)

Well this was a surprise! No wonder Agile is over with Alexander in our diagram – Alexander was a formative influence in its very creation!

Digging Deeper into the Alexander-Agile Connection

This discovery left me curious to track down the point where Alexander’s thinking started wielding an influence on software development. I believe I found it. At a significant gathering of computer programmers in 1987, Kent Beck (father of the Agile approach called XP or eXtreme Programming) & Ward Cunningham (inventor of the wiki9presented a technical note in which they wrote:

We propose a radical shift in the burden of design and implementation, using concepts adapted from the work of Christopher Alexander, an architect and founder of the Center for Environmental Structures. Alexander proposes homes and offices be designed and built by their eventual occupants. These people, he reasons, know best their requirements for a particular structure. We agree, and make the same argument for computer programs. Computer users should write their own programs. The idea sounds foolish when one considers the size and complexity of both buildings and programs, and the years of training for the design professions. Yet Alexander offers a convincing scenario. It revolves around a concept called a “pattern language.”

A pattern language guides a designer by providing workable solutions to all of the problems known to arise in the course of design. It is a sequence of bits of knowledge written in a style and arranged in an order which leads a designer to ask (and answer) the right questions at the right time. Alexander encodes these bits of knowledge in written patterns, each sharing the same structure. Each has a statement of a problem, a summary of circumstances creating the problem and, most important, a solution that works in those circumstances. A pattern language collects the patterns for a complete structure, a residential building for example, or an interactive computer program. Within a pattern language, patterns connect to other patterns where decisions made in one influence the others. A written pattern includes these connections as prologue and epilogue. Alexander has shown that nontrivial languages can be organized without cycles in their influence and that this allows the design process to proceed without any need for reversing prior decisions

Hmm, this tempts me to dive a little deeper than I intended to go inside this particular inquiry. But oh well, what the heck. Let’s go there. Yo see I have been aware for a while that at some point someone needs to properly explore the relation between Alexander’s work on pattern languages (which permaculturalists are very fond of) and his work on the design-implementation relationship inside a nature-mimicking organic unfolding process (which permaculturalists seem to have missed or at least not mentioned if they are aware of it). For, as Alexander stressed more and more throughout his career, the two are intertwined to the point of being inseparable if the application of either is to be done justice.

In the above snippet, which I believe marked the start of Alexander’s enormous (if completely unintentional) influence on the software development world, Kent and Ward convey at least two significant aspects of Alexander’s pattern language concept when applied as he intended:

  • As soon as you start breaking down the boundary between design and implementation you start breaking down the boundary between designer and user. The user becomes a design participant rather than a design recipient.
  • You can do this incrementally and iteratively in a way where you can implement bit-by-bit (where implementation is inside and integral to design rather than happening afterwards) and yet not have to then go back and reverse a prior decision. In their words, “nontrivial languages can be organized without cycles in their influence and that this allows the design process to proceed without any need for reversing prior decisions.” Alexander himself came to call these “backtrack-free sequences,” which we will return to in a very practical way later in this inquiry.

Now Kent and Ward don’t in the above statement clarify fully what they mean by “a radical shift in the burden of design and implementation.” But given that a cornerstone of the subsequent development of the Agile approach (Which Kent and Ward were key players in) is moving away from CDDUF (concept & then a detailed design up front) toward CDDAYG (concept and detailed design emerges as you go) with a crazy-tight continuous iteration between designing and implementing (and hence designer and user or client) I think it’s clear they were tuned into the significance of this stuff from the start. They got pattern languages. But they also got the idea that the patterns therein work their best only inside a generating as opposed to a fabricating process.


Wow. Epic. When I casually googled “design process” at the beginning of the last post, I had absolutely no idea what I was getting myself into.

We’ve seen that Alexander’s critique of the conventional separation and chronological sequencing of design and implementation has triggered massive, global-scale transformation in the software design community (via the Agile movement). This transformation is being embraced and channelled in almost every direction imaginable.

Despite permaculture’s soft spot for Alexander’s pattern language concept, Alexander’s more fundamental ideas about the character of nature-mimicking design in terms of what it means for the relation of design and implementation do not yet seem to have been fully appreciated (at least to the point you find this stuff mentioned in the permaculture literature).

In spite of this, I have detected a movement inside part of what we might call the cutting edge of permaculture design away from CDDUF (completing a concept and detailed design up front before implementing) and toward CDUFDDAYG (concept design up front then detailed design emerges as you go).10 In David Holmgren and Ben Falk’s case we’ve even seen an inclination towards going a step or two further into the land of CDDAYG (concept and detailed design emerges as you go) – the land Alexander and the Agile folk appear to reside.

Now I don’t know what you make of all this, but I personally would venture the following conclusion. In at least one important respect, many modern software designers are using design processes that are more sophisticated, more throughly researched and crash tested, more adaptive, and in some ways even more nature mimicking than the processes used (or at least publicly taught and communicated) by permaculture designers, who ostensively are all about mimicking nature!11

What is up with that!?!

One might even go so far as to claim that in its insularity from design science in general, and software development process in particular, permaculture as a whole has quite simply been left behind when it comes to the best and most effective design process understandings.

Yes, at the end of the day this stuff has been used in software design to more efficiently generate, well, software. I am not saying the stuff it creates there is necessarily of that much interest to permaculture.12 I am saying that the way in which it creates that stuff maybe should be, given that it is some important ways several steps ahead of the game.

As a permaculturalist, I have to admit I found this all a little embarrassing at first. But in a good way! In a motivating way! In a “sleeves up people – we got some catching up to” do kind of way.

The findings of this post have clear implications for our inquiry. In a twist I never would have expected, as we strive toward a fresh and more internally consistent conceptualisation of permaculture design process, we’ve realised that as counterintuitive as it may seem for people interested in real plants and animals and water and soil and sunlight, the agile movement in contemporary software programming may have a lot to teach us about getting better at what we do in our own domain.

In the next post, I’ll start introducing some field-experiments13 where I’ve been putting some of these ideas to the test on the ground.


On the Relation between Designing and Implementing in Permaculture – Part 7

Rafter Sass Ferguson1 has drawn attention to permaculture’s insularity or relative lack of mutually-enriching interaction with complementary developments and disciplines.2

Agreeing this insularity is a weakness, at this stage in this inquiry3 I’ve decided to zoom right out. Leave permaculture design alone for a moment. Leave Christopher Alexander’s thoughts about design alone for a moment.4 Zoom right out and see if I can find any relevant or useful developments or discussions in the field of design in general.

After writing the above, about ten seconds into my quest, I checked out the wikipedia entry for design. I was gob-smacked with what I found. Accordingly, here, in today’s post, I invite you to take a deep breath, and, if you wouldn’t mind, holding my hand as we venture forth into a plot-thickening can of worms.

In a section titled Design as a process, the entry explains

Substantial disagreement exists concerning how designers in many fields, whether amateur or professional, alone or in teams, produce designs. Dorst and Dijkhuis argued that “there are many ways of describing design processes” and discussed “two basic and fundamentally different ways”…

The prevailing view has been called “The Rational Model”…

The alternative view has been called “The Action-Centric Perspective”.

While you can of course go read the full entry for yourself, the following excerpts sum up the gist of the difference.

The Rational Model (and its uncanny resemblance to standard presentations of permaculture design)

The Rational Model posits that, amongst other things…

the design process is understood in terms of a discrete sequence of stages

…where typical stages include:

  • Pre-production design
    • Design brief…
    • Analysis…
    • Research…
    • Specification…
    • Problem solving – conceptualizing and documenting design solutions
    • Presentation…
  • Design during production
    • Development – continuation and improvement of a designed solution
    • Testing – in situ testing a designed solution
  • Post-production design feedback for future designs
    • Implementation – introducing the designed solution into the environment
    • Evaluation and conclusion – summary of process and results, including constructive criticism and suggestions for future improvements
  • Redesign – any or all stages in the design process repeated (with corrections made) at any time before, during, or after production”

The Rational Model underlies the so-called waterfall model of design process:

The waterfall model is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.

In light of my earlier review of different contemporary presentations of design process, does this ring any bells? Consider the lists of stages in this table with the above example lists of stages in the above descriptions of both the rational and waterfall models. The resemblance is uncanny.

Criticism of the Rational Model

In a section with this same title, the wikipedia design entry next explains that:

The Rational Model has been widely criticised on two primary grounds:

  1. Designers do not work this way – extensive empirical evidence has demonstrated that designers do not act as the rational model suggests.5
  2. Unrealistic assumptions – goals are often unknown when a design project begins, and the requirements and constraints continue to change.

The Action-Centric Model

Enter the contrasting action-centric model, “a label given to a collection of interrelated concepts, which are antithetical to The Rational Model.” In the action-centric perspective (amongst other things):

no universal sequence of stages is apparent – analysis, design and implementation are contemporary and inextricably linked

The page then explains a few Action-Centric views of what actually happens as you design. One of them is called the Reflection-in-Action paradigm which this paper by Paul Ralph (2010) explains as where:

…design is a reflective conversation between the designer and the situation. The designer alternates between framing (conceptualising the problem), making moves (where a move is a real or simulated action intended to improve the situation) and evaluating moves.

Needless to say, in the phrasings I’ve been developing over the last few posts, this smacks of what we’ve been calling a generating (or CDDAYG), as opposed to a fabricating (or CDDUF) approach.


To put all this another way, in the terminology of the wikipedia design entry, what this wider (multi-post) inquiry has been exploring is:

  • the permaculture design literature’s current resonance with the rational model of design process (see hereand
  • permaculture’s internal murmurings of concern at aspects of this model, with regular hints, inclinations, graspings, or outright leaps towards something more akin to an action-centric model (see here).

Where to From Here?

On the scent of something that might have real value for this inquiry, I kept sniffing. It didn’t take much to start honing in on something more specific than general design models or paradigms. Something very interesting indeed.

First, from the discussion around the action-centric design approach on the wikipedia page I found myself on the page for something called Iterative and incremental development, where:

The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.6

From there I struck what for the current inquiry is a veritable gold mine. It started with repeated reference from the cluster of related concepts including action-centric, reflection-in-action, and iterative and incremental development, to something called the Agile approach, which by all accounts appears to be the best known and fastest-growing application of all these ideas in real design applications.

In the next post, we’ll check it out.


Ralph, Paul. “Comparing Two Software Design Process Theories.” In International Conference on Design Science Research in Information Systems and Technology, 139–53. St. Gallen, Switzerland: Springer, 2010.
Rohr, Jascha, and Sonja Hörster. “THE FIELD-PROCESS-MODEL,” date unknown.


On the Relation between Designing and Implementing in Permaculture – Part 6

Well, here we are, having arrived at post six in an inquiry into the relation between designing and implementing in permaculture. Let me recap what’s come so far, using some acronyms1 that make it much easier (for me at least) to understand what is actually going on here. Turns out to be pretty simple.

The first and second posts established that, despite a few sometimes subtlety worded concerns, cautions, and disclaimers, the literature of permaculture design process advises/endorses/models completing a concept & then a detailed design up front (CDDUF) as in before you start implementing.

The third, forth and fifth posts consulted an acorn and then Christopher Alexander’s critique of the CDDUF approach. Alexander characterises CDDUF as an inherently mistake-prone fabricating process and instead recommends a generating process where the (presumably concept and detailed) design emerges as you go (CDDAYG).

To condense everything we’ve covered so far into two bullet points…

  • Permaculture literature gives impression that CDDUF is cool (and that subsequent feedback can sort any issues)
  • Nature (as represented by an acorn) and Christopher Alexander counter that CDDUF is not cool (regardless of subsequent feedback) implying or saying that to the contrary CDDAYG is cool

…or into a simple diagram:

Now the idea for this sixth post came from this question: Out of all the experienced permaculture designers out there who have taken the time to share what they have gleaned through years of design practice, if this CDDUF vs CDDAYG stuff really is an issue, surely some must have already considered it? I mean why reinvent the wheel if we can find some in-house clues and paths toward resolving all this, right?

Of course they have! Pulling a few volumes out of my (limited) library, and dialling up a few relevant podcasts, let’s look over what a few of them have to say, starting with the big man himself.

Bill Mollison

In his epic Designer’s Manual, Bill Mollison (1988) focuses on a bunch of different design methods as opposed to the design processes such methods sit within. This has lead some (otherwise sympathetic) commentators to say things like:

But when it came to teaching how to actually do the design itself, even Bill Mollison’s Designers Manual – a weighty compendium on permaculture – went silent (Jascha Rohr & Sonja Hörster)2

While I agree,3 I would add that he didn’t go completely silent. There are helpful whispers, even if a little bit of reading between the lines is required to draw them out.

Consider his Methods of Design chapter. Under the heading The Establishment and Maintenance of Systems (pp. 65-68), we find some at-first-glance contradictory emphases:4

On the one hand, Bill says things like:

Because impulsive sidetracks are usually expensive, it is best to fully plan the site and its development, changing plans and designs only if the site and subsequent information forces us to do so

and, as a first step…

Design the site thoroughly on paper

On the other, he says things like:

Instead of leaping toward some imaginary end point, we need to prepare the groundwork, to make modest trials, and to evolve from small beginnings. A process of constant transition from the present to the future state is an inevitable process…

Thus, our design methodologies seek to take into account all know intervening factors. But in the end it comes down to flexibility in management, to steering a path based on the results of trials, to acting on new information, and to continuing to observe and to be open or non-discriminatory in our techniques

In all of this, design methodologies plus management is involved, and it is therefore far better to train an owner-designer who can apply long-term residential management than to evolve a roving designer, except as an aide to initial placements, procedures, and resource listings

To me, these latter statements strongly support more of a generating than a fabricating approach, given that, one more time, in the end…

…it comes down to flexibility in management, to steering a path based on the results of trials, to acting on new information, and to continuing to observe and to be open or non-discriminatory in our techniques5

These seemingly contradictory emphases are complementary on a closer reading. Bill suggests that yes, it is essential to complete some kind of whole-site plan up front, and to think through a sound starting point and sequencing of subsequent stages of development. But then, you get the development/implementation process underway, where you complete more detailed nucleus designs for different areas in the process of developing them, the prior broad-strokes plan ensuring all the little areas evolve as threads in a coherent larger fabric:

Break up the job into small, easily achievable, basic stages and complete these one at a time. Never draw up long lists of tasks, just the next stage. It is only in the design phase that we plan the system as a whole, so that our smaller nucleus plans are always in relation to a larger plan

I believe this treatment is in some ways more sophisticated that the default idealised (and ultimately linear) presentations of permaculture design process we reviewed at the start of this inquiry. There, a common theme was the recommendation that you craft a concept and detailed drawn design before commencing implementation (CDDUF). Yes, feedback then kicks in, but the flavour I get (or maybe extrapolate is more accurate) from Mollison’s words above, is know your clients and the site, get the big picture layout and staging sequence sorted, then figure out (or even better empower the owner-residents-managers to figure out) the details as you go along.

This is an exciting development! Thanks to Bill Mollison, we have found the beginnings of a potential resolution of the fabricating/CDDUF and generating/CDDAYG dichotomy. It is a hybrid we might call concept design up front then detailed design emerges as you go or CDUFDDAYG.

A continuum now emerges, and based on the above statements from Mollison, I’m putting him in the middle:6

In terms of the fabricating vs generating diagram in our last post, CDUFDDAYG entails a little run of decide-draw-decide-draw up front and then jumps across to decide-draw-do-decide-draw-do for the bulk of the journey. The idea being that you do just enough fabricating to make sure you’re not about to get yourself in trouble, and then it’s generating time. Here’s an update adding CDUFDDAYG to the diagram from the last post (click to enlarge or here for PDF version):

David Holmgren

Check out this gem of relevant insight7 in David Holmgren’s 1994 (republished as ebook 2006) Trees on the Treeless Plains. In the chapter titled The Planning Process, David writes:

There is a role for input from a large range of professionals including landscape designers, but it is the landholder who must become the lead planner. Only the landholder can consider and balance all the strategic, technical and practical elements which make a whole farm and develop a plan which can grow and change over time.

General Eisenhower once said “plans are useless but planning is essential”. In other words, planning is a process rather than bits of paper, or put another way, strategic planning rather than master planning.

Master planning, (where detailed plans are implemented producing a final fixed state which is a copy of what is on paper) has been discredited in the planning profession due to its failure to deal with complex evolving systems such as cities. Many attempts at farm planning by consultants, including soil conservation officers and landscape architects, have tended to be master plans which encourage the notion of a final state for the landscape and farm. It might be noted that the final state for everything is death.

In strategic planning, the emphasis is on processes of development which are on-going and respond to changing circumstances. It recognises that complex systems can never be completely described, predicted or controlled but that forces can be identified and worked with to develop a more balanced and productive system. Most importantly, strategy planning can help pinpoint the initial step to get the desired processes moving without later having to undo what has already been done. (p. 21)8

Here we find an unambiguous rejection of CDDUF. One more time:

Master planning, (where detailed plans are implemented producing a final fixed state which is a copy of what is on paper) has been discredited in the planning profession due to its failure to deal with complex evolving systems…

Furthermore, David’s strategic planning in the above passage comes dangerously close to what Alexander might call a pure generating (as opposed to fabricating or part fabricating / part generating) process. Dangerously close! Indeed, in stressing getting the “desired processes moving” as an initial step and “processes of development which are on-going and respond to changing circumstances” he appears to leap-frog right over CDUFDDAYG into CDDAYG territory! To repeat (for the emphasis it deserves):

Most importantly, strategy planning can help pinpoint the initial step to get the desired processes moving without later having to undo what has already been done9

Now it would be disingenuous of me to go ahead and pop David into the CDDAYG spot (alongside Bill) and leave it at that. For David does elsewhere discuss and model the process of getting at least a concept design together before starting implementation. Consider these statements from Melliodora: Hepburn Permaculture Gardens (1995, republished as ebook 2005), which is by-far his best documented design project:10

I can design, or help design the skeleton or framework  within which clients may develop permaculture as a living evolving system. However, I cannot apply myself to someone else’s design, the way I have to our own. Clients could not afford the cost and I would not be prepared to devote the time and creative energy required. The living, evolving system which we call permaculture can only come about as a result of the continuous interaction between the client as designer/practitioner and the elements of climate, soil, plants, animals, buildings and people (p. iii)

A general design concept had been worked out prior to the earthworks but this was modified following exposure of resistant sandstone reefs… (p. 17)

Although there are great dangers in designing a house in isolation from site factors, a conceptual design can help in selection of land and siting within that land. Being owner/designer/builders makes modification to design details during construction also possible. Moving into the house before it was fully finished allowed further refinement of design details. (p. 23)11

In a final relevant snippet, in Permaculture: Principles and Pathways Beyond Sustainability (2002) David explains that:

…finding the appropriate pattern for that design is more important than understanding all the details… (p. 127).

The implication of this last batch of quotes for our current inquiry is crystal clear. David is speaking from CDUFDDAYG land. He is explicitly referring to the idea of completing a “general design concept” or “conceptual design” before commencing implementation/development as a “living, evolving [i.e., generated] system.”

The upshot is that, taking a sort of average of the above quotes I’m placing David Holmgren until further notice with a foot in both the CDUFDDAYG and CDDAYG camps:

Dave Jacke

In a hyper-relevant recent email comment he’s kindly given me permission to share, design process powerhouse and ubermentor Dave Jacke explained that his statement in Edible Forest Gardens (2004, V.2 p. 313) starting “Implementation is the next phase of your work, and the last piece of the design process”…

…is spoken from the place of assuming a linear process, which almost never actually happens! But in the linear model, that quote is the idealized flow. In reality, I design the overall pattern, implement key pieces after designing them, then redesign as more parts of the system get implemented. I have never had a client where I could implement all at once as a grand expedition! It’s always been piecemeal implementation with design along the way, responding to changes in goals, site and emergent reality as the design goes into place. But having a big picture view, that is, an overall site design to at least a schematic level, is critical to help one work out where to begin the implementation. Then I would design the relevant patches, including their site prep and implementation strategies, and then proceed on the ground. Staking out is a critical part of the process!  Field testing the design in reality, essentially (from a personal email communication received January 28, 2017)

This is an important comment, particularly given it comes from one of the most influential (if not the most influential) permaculture/ecological design process thinkers on the planet right now. For my current focus the most signifiant parts are:

having a big picture view, that is, an overall site design to at least a schematic level, is critical to help one work out where to begin the implementation.


In reality, I design the overall pattern, implement key pieces after designing them, then redesign as more parts of the system get implemented … It’s always been piecemeal implementation with design along the way, responding to changes in goals, site and emergent reality as the design goes into place

In terms of our shiny new continuum, while Dave’s book would, on a superficial reading at least, land him over on the left hand side, this more recent sharing of what he actually does in practice lands him squarely in the concept design up front then details emerge as you go or CDUFDDAYG camp.12

Ben Falk

Earlier in this inquiry we shared Ben Falk’s statement that:

Master plans are not solid, set-in-stone documents–although everyone wants them to be. Heck, I am hired many times largely because people want a plan that’s solid, unwavering, and something they can follow now and in ten years. Sorry-they don’t exist. Most plans are iterative. And despite the authoritative sounding name, master plans are no exception. A good ‘master’ plan is a working plan-in other words, it’s the latest version of good approaches. It will change: that much is guaranteed. The important  part to remember is that it’s a guide for next decisions, not an ultimate life map or site oracle. Land and the lives unfolding for them are far too complex, unpredictable, and mysterious for any vision of a ‘way’ to hold up year after year. (The Resilient Farm and Homestead, 2013, pp. 72-77)

Consider now his statement, in a 2013 podcast with interviewer Scott Man, that:

Although I make most of my living as a planner and site designer I am learning more every year the limits of that planning process and how inherently limiting it is. It carries a lot of power with it, carries a lot of weight, but most of the time too much weight. It’s easy to just take paper too seriously and have too many decisions based on what is or isn’t on a piece of paper. It can be great to guide overall decisions and to know starting points and know general steps but if it’s not coupled with the active hands on that constantly changes what’s on that paper master plan/site design it can be very misleading and very dangerous.

Ben’s words here display remarkable resonance with those we’ve shared of David Holmgren’s. Like David, Ben voices strong concerns with any kind of fabricating or CDDUF (concept and detailed design up front) approach. In particular, he hones in on CDDUF’s dangerous tendency to then influence implementation decisions such that the much more important reality of what is actually unfolding on the site gets overruled.

As far as the little diagram I’m developing here goes, these statements land Ben with David Holmgren. To me, this comment (from the same podcast) seals the deal:13

More and more every year I rely on the planning process as identifying general steps and starting points and trying to visualise … an idealisation of what a place might be in 10 -20 – 50 years, but really using the planning process to identify starting points and letting those starting points then organically drive the actions following those starting points.14

Let’s face it, Ben. You are an anti fabricator. You are at heart a generator, and you’re living and designing dangerously close to crossing the line and diving into pure CDDAYG:


Well this has been a bit of fun, I tell you. It is quite gratifying to simplify some aspect of complex reality into several pigeon holes then to casually slot respected senior colleagues and teachers in here or there.15

The upshot is this. Despite the idealised, linear CDDUF approach presented and modelled in all the published presentations of permaculture design process16 I am aware of (shown clearly in my review starting here), at least four of permaculture’s most well-known and/or cutting-edge design thinkers (including both co-originators) on examination either explicitly criticise this approach or don’t use it in practice!

This a striking internal contradiction within permaculture. Evidently thousands of people are being taught an approach to permaculture design (based on what is in the books) that some of the most considerate permaculture design thinkers in the world reject on the grounds that it doesn’t work!17

The design process authors and practitioners we’ve considered in this post, with a bit of extra research (David Holmgren, Ben Falk), email correspondence (Dave Jacke), and reading between the lines (Bill Mollison), advocate and/or practice entering the realm of implementation and active doing before a detailed design is completed.

We started this post with the seeming dichotomy between CDDUF or fabricating processes and CDDAYG or generating processes. Thanks initially to Bill Mollison, we found a middle path in CDUFDDAYG.18 At least in the sources we consulted, Bill Mollison and Dave Jacke espouse CDUFDDAYG (a fabricating-generating hybrid approach). So do David Holmgren and Ben Falk, though these two also show definite sympathies for CDDAYG. Hence the relative location of the four authors in my evolving little diagram:

So with CDUFDDAYG or a CDUFDDAYG-CDDAYG blend (namely the space inside the red line in the diagram) have we have arrived at a happy ending? Maybe. Maybe not. My feeling is we’d best let the dust settle and look around a little more before holding hands and dancing in a circle. I for one would like to see what others make of all this before getting too carried away.

That said, we’ve without doubt happened onto a promising development. With CDUFDDAYG (or this plus a dash of CDDAYG) we have an approach with scope to avoid both the rampant mistake making Alexander claims is unavoidable in CDDUF  and the blindingly obvious concern that if you leap straight into CDDAYG that you’ll land in a mess of conflicts, major mistakes, and dead ends.19

Hmmm. Food for thought, hey? In the next post we’ll zoom out and see if we can find any guidance on these matters from the wider universe of design thinking and practice.

Meantime do tell me what you make of the continuum. Is it any use to you? Where do you sit in your design work, and are you on the move? If so, what is your trajectory? Do you agree that almost all publicly accessible presentations of permaculture design process are, on the surface of things at least, over in CDDUF land? Or can you share any documented examples of something different? Do you have any relevant quotations you’d be happy to share?

I really, really appreciate your comments. This stuff is written and shared in service of the global permaculture community, and in your comments I get valuable feedback as to how to that might be done better in future (not to mention motivation to continue!).


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.
Falk, Ben. The Resilient Farm & Homestead, 2013.
Holmgren, David. Trees on the Treeless Plains: Revegetation Manual for the Volcanic Landscapes of Central Victoria. Holmgren Design Services, 1994.
Holmgren, David. Melliodora: Hepburn Permaculture Gardens. Holmgren Design Services, 1995.
Holmgren, David. Permaculture: Patterns and Pathways Beyond Sustainability. Melliodora, 2002.
Jacke, Dave, and Eric Toensmeier. Edible Forest Gardens: Ecological Design and Practice for Temperate Climate Permaculture. Vol. 2. 2 vols. Chelsea Green, 2005.
Mollison, Bill. Permaculture: A Designer’s Manual. Tagari, 1988.


Once again a big thanks to James Andrews for feedback on this and all other posts in this inquiry.


On the Relation between Designing and Implementing in Permaculture – Part 5

Building on the last post this post goes deeper into the beef of both an acorn and Christopher Alexander with the culturally (and, as we’ve seen, permaculturally) ingrained practice of completing a detailed design before implementing it.1

For me, the problem becomes particularly clear when I consider that all design processes are decision making processes. To design, that is, is to make a series of decisions.

Imagine you’ve drawn up a detailed permaculture design on-paper (or on-computer) such as the example here (one of my earliest professional designs).

Imagine choosing an object. A garden bed, an apple tree, a path, whatever. Now consider Alexander’s observation that:

When we examine an object, we may see that each element in the object (part, line, edge, position, color, size) represents a decision. In very rough terms, we may that each line represents a different decision. We may also say that each line has created space on either side of it and near it, and therefore typically represents some four or five decisions about space (through size, convexity, adjacency, organization).

Each element has the possibility of being wrong. By that I mean the element as placed, sized, and oriented, may be well-adapted to its neighbours, to the space around it, to the conditions which exist, and to the conditions arising from the structure of the surrounding elements – or it may be badly adapted to the neighbours, conditions, space, trees, arising from surrounding elements.
We are going to count the number of possible mistakes, and try to estimate how many of these mistakes have been avoided, and how many have been committed, in different types of plan. It is here, that we shall see the vast superiority of generated plans. They avoid mistakes. A fabricated plan cannot avoid mistakes, and in all fabricated plans, the overwhelming majority of possible mistakes, are actually committed (2002, p. 186).

Here Alexander makes a distinction between what he calls generated and fabricated plans. The details of a fabricated plan arise in the process of creating the plan prior to implementing or creating it. The details of a generated plan, in contrast, unfold or emerge through time inside (rather than outside and up front of) the very process of implementing or creating it:


Consider the hundred or so permaculture design examples here, examples I personally had a hand in. Consider the example of permaculture designs given in youtube videos like this or this or this. In terms of the current analysis, these designs constitute the aggregation of hundreds or even thousands of decisions, all, it seems, made on a piece of paper before any implementation.

If Alexander is right, many of these decisions are likely to be mistakes, or at least not as on-track as they would be if they were made at a more appropriate moment in the actual unfolding of the garden or space being designed and created.

Towards getting as clear as possible on what the difference between fabricating and generating might look like in a permaculture design context, see what you make of this diagram (you can also click to enlarge or download it here as a PDF if hard to see):

As is hopefully decipherable from the diagram, in both approaches you start with a decision that needs making (such as where the new driveway will go). Then, in both approaches, you survey your options (or different ways of making that decision, such as the driveway could go like this, or like that, or what about around here like this? etc). You then, in whatever way, test the options and select one. The type of testing is not relevant here – it might involve thinking, doodling, marking out on site, consulting experts, whatever. The point is that one way or another you make a decision – you select an option. Now, again in both approaches, you draw in that decision on your plan (for example you might draw in where you’ve decided is the best spot for the new driveway).

Here is where the paths diverge. In the fabricating approach the just-drawn-in decision prompts another decision, and you re-enter another round of the same sequence you’ve just completed. In the generating approach, you go out and actually implement that decision on the ground. The actual reality of the implemented decision (for example the actual driveway itself once installed) now prompts and provides a context for making the next decision.

In the fabricating process the rhythm is therefore decide-draw-decide-draw-decide-draw before moving on to a big chunk of (post-design) DOING. In the generating process the rhythm is decide-draw-do-decide-draw-do-decide-draw-do such that the designing and drawing only get ahead of doing by a decision or two.

Perhaps the key to it is that in a generating process, apart from the first decision, all key decisions are directly prompted by the just-updated reality of the site. In a fabricating process, by contrast, apart from the first decision, all key decisions are directly prompted only by the just-updated reality of a drawing of the site.

Alexander claims (and I obviously think he has a point) that 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.  You are engaging in some degree of fantasy,2 and you will get off track.


Christopher Alexander makes a strong case that the process of completing a detailed design before implementing it (fabricating in his language) is inherently flawed. If we wish to create systems more akin to the rest of nature, Alexander agues we must us a generating process, where decisions are made inside and during the creating process, not before it.

For Alexander, in a healthy process able to generate nature-mimicking systems:

Each … decision,3 is made in sequence and in context. It is worked and reworked right then and there until it is mistake-free, i.e., it takes into account all the connecting relationships. This must be done in sequence and in context because the necessary information for a successful decision is not available prior to that step in the unfolding. (2002, p. 201)

In the posts to follow we’ll explore some resonant voices both inside and outside permaculture, we’ll further firm up how this might play out in practice, then we’ll get outside and see what (if any) difference it makes on the ground (the only place it matters).


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.


Big thanks to James Andrews for feedback on this and all other posts in this inquiry. Thanks also to those of you starting to comment – it is fantastic to get your thoughts during the inquiry so they can inform and influence what happens next.


On the Relation between Designing and Implementing in Permaculture – Part 4

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!


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.


On the Relation between Designing and Implementing in Permaculture – Part 3

Permaculture was founded on the premise that humans must mimic natural systems if they are to survive (let alone thrive!).

Accepting this premise prompts a rather pressing question: How do we go about mimicking natural systems?

An obvious answer is by mimicking the processes nature uses to generate natural systems.1

This answer prompts another question: What are the key attributes of these processes?

Let us ask this question of a specific natural process example. Take the process starting with an acorn and heading toward a grand old oak tree.

This process is the gradual transformation of a whole-and-its-parts (the acorn with its shell, food store, embryonic plant, etc) toward a different whole-and-its-parts (the oak tree with its leaves, limbs, truck, roots etc).

The transformation happens in a particular sequence.

Once germination is triggered, for instance, the acorn’s first order of business is to organise an anchor.

Drawing down on its in-house larder, cells divide. A root tip emerges. Provisionally anchored and sending out feelers toward water, minerals, microbial allies, and such like, the sequence now starts making moves toward a photosynthetic income stream.

A new growing tip, this time heading up, differentiates itself within the dynamics of the fluidly transforming whole.

Leaves appear. Photosynthesis commences. The growing tip leaves a stem in its wake, which starts to thicken, and stiffen. Enter wood.

And so on.

Something along the lines of this amazing life-unfolding process is happening all around us. It is the formative key to all living tissue, all organism.2

Versions of this process are underway in your body, right now. A wound heals. Fingernails grow.

Even if we stop here, with this simple reflection on one of nature’s life-creation processes, we find discrepancy with how, in modern times, humans use something called “designing” to create form in the world.

This comes as no surprise for most modern design processes, which have no intention to create things that mimic nature.

Take modern architecture, where the intention often appears to be making buildings as unnatural and as unadapted to their surroundings as possible.

(Image source)

But what of permaculture, which from its inception has been, by definition, an approach to the design and creation of nature-mimicking systems?3

Does the average permaculture design process mimic natural process, in the sense of our acorn-moving-toward-oak tree example?

In at least one important respect, it does not.

After a review of nine different contemporary presentations of permaculture design process, the previous post concluded that:

A core idea integral to how permaculture design process is understood and communicated in the permaculture literature is that of completing a design to some satisfactory degree of detail and only then implementing it.

But the acorn does not create a detailed design of the oak tree and only then implement this design.

It literally figures the details out as it goes along. The only place a detailed design appears is in the actual unfolding reality of the tree itself.

The acorn contains something we might say is akin to a goal, in the form of genetically encoded rules constraining or directing the kind and sequence of transformations that take place. This ‘goal’ contains parameters that are different from the parameters encoded in the DNA of a eucalyptus seed, or an elephant embryo.

But there is no specific layout. No detailed design. No blueprint. No master plan. There is no picture to aim toward.

Let’s consult an actual acorn on this:

Us – Listen acorn, why don’t you draw up a detailed sketch of the oak tree you’d like to become first – then you can use the sketch as a guide to move toward

Acorn – What are you nuts? How on earth can I tell how many leaves, limbs, etc etc I’m going to end up with? Why do I even care? Why would I waste my energy creating some imaginary future state that will never, ever correspond to where I actually end up? All I need do is take one step at a time, basing each decision based on what makes sense for the reality of where I am at in that moment (which includes my DNA, current environmental influences, my current size and shape and stage etc etc)

Us – No seriously, you should listen to us. After decades of practice, we’re convinced you’re much better to make mistakes on paper first, so you get things right on the ground, and, err, up in the air

Acorn – Again, this is crazy talk. My ancestors have been researching this stuff for well over 300,000 years and I can tell you with certainty that the surest way to make mistakes with this creating natural systems stuff is to try and plan all the details out in advance. Just relax, figure out what comes next, make a move, plan the next step, then repeat. Seriously, take a leaf out of nature’s book, why don’t you?

In the next post, I’ll dip my toe into the work of a human designer-creator who has done just that.