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.

Endnotes

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.

Endnotes

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

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.

Summary

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.

Endnotes

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.

Recap

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.

References

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. https://pdfs.semanticscholar.org/12e4/5521bf4ca5edf3c4acdaf6076be7cdbb307a.pdf.
Rohr, Jascha, and Sonja Hörster. “THE FIELD-PROCESS-MODEL,” date unknown. http://www.partizipativ-gestalten.de/the-field-process-model/.

Endnotes

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.

and…

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:

Summary

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!).

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.
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.

Acknowledgements

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

Endnotes

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.

Summary

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

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.

Acknowledgements

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.

Endnotes

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!

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.

Endnotes

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.

Endnotes

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

Though the high-level side-by-side comparisons I shared in the last post have their place, it would feel inappropriate to reduce each of the design process treatments we looked at in the last post to only one column in a table. Here, in the second post of our second inquiry, I review each treatment in more detail, attempting to do at least some justice to the nuances of the thinking behind each process description, and focusing in particular on the author’s presentation of the relation between the designing and implementing phases of the process.

A More Detailed Breakdown of Current Permaculture Understandings of Design Process

As per the table, I’ll start with books, consider one article, then look through several easy-to-find online treatments.1 Here is a table of contents to help you see the line-up and get around:

If you’re short on time or interest, or just want to see if this joke is funny or not, be my guest and jump right on down to the punch line in the post summary below, or across to the next post (which will be published within a week of this one)

Dave Jacke (Edible Forest Gardens VII)

Chapters Three and Four of Dave Jacke and Eric Toensmeier’s Edible Forest Gardens Volume Two (2005) contain what is perhaps the permaculture literature’s most profound and influential presentation of design process, even if Dave, who wrote these chapters, referred to it there as a forest-garden design process, and nowadays prefers to call it an ecological design process.

Early on Dave warns against treating design process as “clean, linear, and organised” and as “rigidly following an idealised design-process outline, even ours” (p. 142). As he puts it:

Design is an elusive and enigmatic alchemy. Yet the magic of design lives, not in any design technique we might learn and use, but inside each one of us. The techniques serve only as touchstones to connect each of us to our own living creative process. Do not confuse the finger pointing to the moon with the moon itself. (p. 141)

…where, despite this…

Like the forest, the design process is complex and multilayered, yet both have structure. Certain principles and “archetypal” activities undergird every effective design process, yet each trip through it is unique (p. 142)

…and, despite the way or order in which you engage with them…

When we take apart an idealized forest-garden design process we can see six fundamental, interrelated actions:

  • Goals articulation
  • Site analysis and assessment
  • Design concept development
  • Design
  • Implementation
  • Evaluation

In more detail, Dave breaks the overall design phase into conceptualschematic, detailed, and patch design sub-phases.2

Bringing our focus towards the threshold between design and implementation, in the detailed design phase Dave recommends that:

…ultimately you should aim to create hard-line drawings detailing the exact size, shape, and location of every element (p. 271)

…giving this example…

(This diagram is adapted from Edible Forest Gardens, Volume II by Dave Jacke with Eric Toensmeier (October 2005) and is reprinted with permission from Chelsea Green Publishing.)

…then, as the last design phase (or sub-phase, if you prefer) before implementing…

In the patch design phase, you determine the species composition, patterning, and spacing of your garden plantings patch by patch to a high degree of specificity (p. 286)

…where, overall, his point is that…

We must design the details of that [design concept] whole to a point where we can gather the materials, energy and money necessary to create it, or at least identify logical first steps (p. 142)

…then, after evaluating your design and the process you’ve used to get to it,3 Dave explains:

Implementation is the next phase of your work, and the last piece of the design process. Site preparation usually comes first, followed by staking out the design on the ground and making final adjustments. Then you can plant. (p. 313)4

In subsequent chapters, Dave addresses Site Preparation, Garden Establishment, and Management, Maintenance and Co-evolution.

To summarise for the purposes of our focus in this inquiry, in the idealised design sequence given in Edible Forest Gardens, you complete a detailed design before implementing it.

Ben Falk (The Resilient Farm and Homestead)

Like that of Dave Jacke, Ben’s take on design process in this 2013 book stands out for its thoughtfulness, originality and high calibre.5 Indeed for Ben, design is more of an ongoing attitude than a process with a defined beginning or end. In his words:

It is essential to remember that this [design] process does not stop once the shovel hits the ground. Designing is a constant state of being, and when engaged in the world as a problem solver, you never turn off the tendency to notice a sub-optimal situation and think systematically about how to improve it. Design process can take many forms, and no one approach can be prescribed as the best for all people and all scales. However, it can be said that any effective design process is rooted in intense engagement with the problem at hand and the world in which that problem resides. (p. 24)

Early in his design process and site establishment chapter, Ben shares a simple diagram showing the planning and design process as an endless cyclic interplay between analysis (see, observe, study), interpretation (consider, decide, affect, apply, mimic) and action (disturb, construct, implement, manage). The diagram blurb reads:

site planning should be continuously fed by a never-ending process of analysing, interpreting, and acting.

In another relevant passage, Ben explains that in light of feeling overwhelmed with the unknown at the start of a path toward regeneration and resilience:

A structure for sifting through the seemingly endless variables is needed. Enter a process. Its beauty is its ability to narrow down options; its danger is in missing solutions that may be important. It is important to begin with two foundational elements: (1) you and (2) your place (or intended place). The rest of the design process can flow effectively from these two starting points but only if it is informed by the existing conditions of you and your place. (p. 46)

Like Dave Jacke, after many such insightful introductory comments (including a fascinating list of 72 novel design principles ), Ben proceeds to talk and share an example journey though a sequence of steps starting with the foundational elements mentioned in the above quote and ending with what he calls a working master plan.

Here’s the sequence, noting that he recommends reversing the order of the first two steps if you already have your land:6

  • Goals identification and requirements of the design
  • Assessing the site / land analysis
  • Design criteria
  • Imagination
  • Schematic design
  • Working plans and implementation documents

Ben emphasises the critical importance of treating the master plan, or as he prefers to call it, master working plan or simply working plan as highly malleable in light of what actually happens throughout its implementation:

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.

And they have one more primary purpose: to avoid huge mistakes–for instance, not putting the house in the wrong place or putting the orchard where a road for the eventual barn will need to go. Such plans are ‘master’ only in that they locate elements that are thought to be inevitable in locations such that other actions can be made down the line. The paralysis that dominates a place when such a plan doesn’t exist, or conversely, the repeated mistakes made when such a plan is not in effect are spectacular. In this way a master or ‘working’ plan is essential. But don’t abuse it–remember, it’s a living document. It must change to remain valid (Ben Falk, The Resilient Farm and Homestead, 2013, pp. 72-77)

To sum up, amongst deep insights about the essence of design, and despite emphasising the malleability of a working master plan for a site once implementation commences, in his shared sequence and examples in The Resilient Farm and Homestead, Ben recommends completing such a plan before implementing it.

Aranya (Permaculture Design: A step-by-step guide)

In his 2012 book Permaculture Design: A step by step guide, Aranya accessibly presents his take on permaculture design process in this sequence:

  • Surveying the site / recording site information
  • Client interview
  • Analysis
  • Placement
  • Design proposal
  • Implementation
  • Maintenance and evaluation

When he arrives at the implementation stage of the design, he explains:

So we are almost at the point now where we can impose our design ideas upon the real world, but first we need to create an implementation plan to guide us (p. 152)

The logic here is clear – complete your design, plan its implementation, then start implementing it.

Toby Hemenway (The Permaculture City)

In this highly-regarded 2015 publication, the late, great Toby Hemenway introduces the idea of a design process as follows:

The point of any design is to move toward some desired outcome-a productive garden, a rewarding business-with as much certainty as possible, some sureness that we’re taking the right steps. Put simply, a design is a plan or set of strategies toward a purpose. The design process, then, is a program for articulating that purpose and for giving us a sure set of procedures for choosing steps toward it (pp. 25-26)

After a rich survey of the various ingredients of what he calls a permaculture design toolkit, Toby explains that we now

…need a process that guides us through design from start to finish. Permaculture designers give their design processes an assortment of names and acronyms, but they all follow the same pattern (p. 45)

Here is the list of steps Toby thinks best captures this pattern:

  • Observation
  • Research
  • Conceptual design
  • Master planning
  • Implementation
  • Evaluation
  • Tweaking

Skipping on down toward our target of the design – implementation threshold, Toby describes master planning as:

…the step that most people think of as design, where the locations and relationships of the systems and elements are put on paper and the organizational structure is laid out (p. 46)

Implementation in turn is where:

…we plan the sequence of tasks that will make the design real, then implement them (p. 46)

Followed by evaluation step, where Toby explains:

In permaculture design [evaluation] is an integral part of the design process. It creates a feedback loop, a defining hallmark of any whole system (p. 46)

Finally, evaluation leads into tweaking, where:

If you did the design well, the changes will be modest, not wholesale revisions (p. 47)

The idea being that you should expect to tweak your earlier design work based on the new information garnered during the process of implementing it. It is interesting here to note Toby’s choice of the word tweak which, as he explains above, implies relatively fine-grained modifications to the already-completed design.

Jessi Bloom and Dave Boehnlein (Practical Permaculture )

In their Practical Permaculture (2015), Jessi Bloom and Dave Boehnlein:

…take a master planning approach to the design process, which means breaking it down into steps that result finally in a master plan. In part 1 of the design process, you will analyze and assess the needs of your site and yourself. By bringing these sets of needs together, in part 2 you will use permaculture design methods to generate ideas that you can evaluate using the principles we discussed earlier. After that, in part 3, you will take the big picture master plan you’ve created and get down to the details of implementing it (p. 59)

In more detail, their design process steps are:

  • initial site observation and getting to know the land
  • development of vision and objectives
  • site analysis and assessment
  • conceptual design
  • schematic design (resulting in master plan)
  • implementation planning
  • detailing and working documents
  • maintenance planning

Again skipping to our point of interest here, Jessi & Dave explain:

During the schematic design step, your goal is to land individual elements on the base map. This means you draw all buildings, roads and paths, water bodies, and other major site features to scale where you intend them to be installed. During this step, it is also important to create multiple iterations of your layouts so you can have several options to choose from (or hybridize) (p. 97)

In terms of the degree of detail, they say that

At the end of this step, you will have a master plan from which to work. (p. 97)

where…

Not all the details of your master plan need to be figured out during this phase, but it should be comprehensive enough to guide you toward your goals (p. 97)

Giving some at least relatively detailed examples of master plans, in the implementation planning step, Jessi & Dave explain:

Once you have you master plan in hand, you’re ready to get to work on the land. (p. 130)

Peter Light (Article in Permaculture Design Magazine)

In his article No Challenge published in the November 2016 issue of Permaculture Design Magazine (downloadable as PDF here),7 permaculturist Peter Light explained:

During the first stage of design… a great deal of time must be spent listening to and asking questions of a client to find out as many details as possible about what the client needs and wants, the functions the building or landscape are meant to fulfill, who will be living, working, or being served by the creation, and so on….

The next step for permaculture is a site analysis…

Once a site analysis is completed… we can begin to start stage three, formulating a design, in head and on paper…

Coming to stage four—the on-ground implementation of the design… (p. 59)

I find this breakdown interesting in Peter’s emphasis that not only are the design and implementation steps separate in time or chronological order, but that for him they also occur in separate places – the design “in head and on paper,” the implementation “on the ground.” Peter refers more than once to the:8

..two separate stages of design work: the on-ground implementation of a design, in the first case; and the formulation of a design in head and on paper, in the second case.9

Given its relevance to our focus on the boundary between designing and implementing, let us explore this a little more. It is interesting to reflect that while this statement is extreme, it is probably not that controversial. The literature of permaculture design does tend to treat design and implementation as not only separate steps in time, but as happening in separate places. Design in the head and on paper, implementation on the ground.

Yet of course no-one would question that the two start dissolving into each other in practice. In Edible Forest Gardens, Dave Jacke has a section discussing the pros and con of designing on paper vs designing on-site, in which he states:

Some people prefer to design on-site to the exclusion of designing on paper. That is certainly fine if it works best for you.

…where on the one hand…

…even if you want to do mostly on-site design, we recommend that you create a rough base map for site analysis and then keep the map and a notebook handy to sketch ideas, take notes, and evaluate options during the design phase.

…but on the other…

at some point everyone will have to stop designing in paper and use stakes, string, and other tools to lay things out on the actual landscape before actually planting or building; some will choose to do this soon rather than later

In The Resilient Farm and Homestead, while giving many examples of designing on paper, Ben Falk stresses that:

There’s absolutely no better way to physically hint at and offer insight into the possible changes (and results) to a place than using large objects to lay out in a space for help in envisaging the changes. We use wood, tires, vehicles, people, barrels, potted plants, rope, chalk lines on the ground, and much more to do this (p. 68)

We sum up this unexpected little side discussion in the below diagram,10 which we assume most permaculturalists, including Peter, would be comfortable with (modifying the degree overlap to suit their preference):

As it is presented, discussed, and exemplified across the literature of permaculture design, designing tends to happen more in the mind and on paper, though of course it also involves on-the-ground marking out / mocking up. On the flipside, though implementation happens mostly on the ground, it ideally also involves evaluating and modifying the design as well.

Appleseed Permaculture (website)

On this page the team from Appleseed Permaculture share this “visual map of the process we use with each of our clients”11

Because their description is so concise and helpful, I repeat it in its entirety:

We begin by collecting the goals and vision from our client. We look for both pattern level goals like increasing on-site food production to specific desires like introducing chickens. We use both pattern and detail level goals to inform the rest of the design process. After our first visit with the client a more formal Goals Articulation Statement will be created.

Next we begin to Analyze and Assess the site. This phase of the design process begins before we arrive on the site by researching soil types, printing aerial photographs of the site and establishing a bird’s eye view of the property in relation to it’s surroundings. Site analysis continues through the initial consultation and depending on the size of the property/project additional site visits will be scheduled. This crucial data collection phase is informed by the landscape. We will be looking at slope, soils, aspect and existing vegetation to name just a few of the already existing landscape features that will support the rest of the design process.

These initial phases form the foundation upon which the rest of the design process unfolds. Now we move into Design. We begin by creating a number of Schematic and Concept Designs. These designs are not detailed and act as a creative canvas, throwing all of our ideas on the table. The point at which our ideas are exhausted we distill down all of the right design elements to be included in the Final Design.

Once the design is complete we move into the Implementation phase of the design process. This is where the plants go into the ground, the pond gets dug and the solar panels go onto the roof. AppleSeed Permaculture specializes in certain elements of Implementation and works with trusted professionals to ensure that all of your desired design elements get installed.

The last phase of the design process is Evaluation. This is where we take a step back. The landscape informs us on the validity of our design decisions. From there the Design Process begins anew. New goals might be formed based on the Evaluation phase and so forth.

The statement with the most bearing on our current inquiry is:

Once the design is complete we move into the Implementation phase of the design process

Very Edible Gardens (website)

On this page I have previously shared the diagrammatic portrayal of permaculture design process my colleague/friend Adam Grubb and I have developed together:12

Note in particular the separate boxes used to indicate design and implementation, the darker arrows showing the suggested chronological sequence of steps, and the lighter arrows indicating the return sweep of feedback from each stage of the process back to its beginning.

Here’s an example of a (pre-implementation) detailed design resulting from this approach:

In summary, in the Very Edible Gardens process you complete a detailed design before moving into implementation.

Occidental Arts & Ecology Center (website)

On this page the folk at the Occidental Arts & Ecology Center explain that:

The permaculture design process consists of several phases: assessment, visioning, designing, and implementation.

In more detail these phases are presented and summarised:

  • Assessment
  • Visioning
  • Designing
    • Conceptual Planning
    • Master Planning and Design Review
  • Element Specifications and Budgeting
  • Implementation

At the Element Specifications and Budgeting stage, the authors explain that:

Once the master plan is complete, each element is designed in detail. Once the element designs are complete, budgets can be created, funding sought, and permits acquired. The sequencing of the implementation of the design takes places as part of this phase.

Here clearly a detailed design is completed prior to its implementation. Then, reminiscent of the return arrows we saw in all the above design process diagrams, the close with the statement:

The design process is a reiterative process that may move linearly through design steps or may circle from one to another and back again. Depending on the information that arises in each phase, steps may be revisited and the design revised.

Summary

This post has examined nine different presentations of permaculture design process as a chronologically sequenced series of steps, stages, or phases.

All these publicly published (and in many cases widely read and respected) presentations are variations on a theme in which:

  • In one order or the other, you tune into people and site.
  • You only then come up with a design, working from patterns (concept/schematic) toward details (master/detailed design).
  • Design completed to a satisfactory degree of detail, you only then implement the design.13
  • You manage/maintain/evaluate the process of implementing the design, going back to tweak, adjust or revise it as necessary.

Many if not all of the treatments emphasise the messiness of the process in reality, the jumping about, the constant iterating back to an earlier phase, and the importance of treating the design as a working plan to keep revising as the project evolves.

In spite of such disclaimers, after what I hope you will appreciate has been a careful and sympathetic reading of each reviewed design process presentation, this post leads me to conclude as follows: 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.

In the next post, I’ll look at a problem with this idea.

Book References

Aranya. (2012). Permaculture Design. Permanent Publications.
Bloom, J., & Boehnlein, D. (2015). Practical Permaculture. Timberpress.
Falk, B. (2013). The Resilient Farm & Homestead.
Hemenway, T. (2015). The Permaculture City. Chelsea Green.
Jacke, D., & Toensmeier, E. (2005). Edible Forest Gardens: Ecological Design and Practice for Temperate Climate Permaculture (Vol. 2). Chelsea Green.

Endnotes

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

In this second Making Permaculture Stronger inquiry, I consider the relationship between designing and implementing within current understandings of permaculture design process. My intention with this inquiry is to:

  • Review contemporary presentations of permaculture design process with a focus on the relation between designing and implementing
  • Explore an issue with the idea of completing a detailed design before commencing implementation
  • Look at how various permaculturalists have previously acknowledged this weakness
  • Look to relevant discussions and developments outside of permaculture for any useful tips or pointers
  • Articulate a way of thinking about design process that helps clarify the issue identified and suggests one pathway toward resolving it
  • share real design process examples to test and attempts toward an improved understanding of how design and implementation might be better related within permaculture design process

As always, the point is not to look critically at basic ideas in permaculture for the sake of it, but towards this project’s goal of strengthening weaknesses toward a stronger permaculture. If this goal resonates with you, I invite your input, comments, corrections, alternative conclusions – all are welcome. One thing I know is that I sure as heck don’t have the answers and that making permaculture stronger will only work if we launch wholeheartedly into such conversations together.1

High-Level Summary of Current Permaculture Understandings of Design Process

In the literature of permaculture, permaculture design process is presented as a specified sequence of generic steps, phases or actions.

I’ve collated nine clear, well-thought out examples in this table (click to enlarge):2

The idea, of course, is that if you are engaging in permaculture design, then running with one of these sequences is a sensible way of going about it.

It seems to me that there are no fundamental differences amongst these various sequences, at least at this top-level summary level. All are variations (some partial, some complete) on a theme in which:

  • In one order or the other, you tune into people and site.
  • You only then come up with a design, working from patterns (concept/schematic) toward details (master plan/detailed or patch design).
  • Design completed to a satisfactory degree of detail, you only then implement the design.
  • You manage/maintain/evaluate the implemented design, going back to tweak or adjust it as necessary.

One sequence implies implementation without listing it explicitly. Though four omit a post-implementation evaluation and feedback phase I either know for a fact or have no doubt the authors would agree on the importance of evaluation and feedback.

In terms of my focus in this inquiry, the upshot of this comparison is this: all these presentations agree that in a sound permaculture design process one completes a detailed design before starting the implementation of that design.

In the next post I’ll examine these nine design process breakdowns in more detail.

Endnotes