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.
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):
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:
In a hyper-relevant recent email comment he’s kindly given me permission to share, design process powerhouse and ubermentor Dave Jacke explained that his statement in Edible Forest Gardens (2004, V.2 p. 313) starting “Implementation is the next phase of your work, and the last piece of the design process”…
…is spoken from the place of assuming a linear process, which almost never actually happens! But in the linear model, that quote is the idealized flow. In reality, I design the overall pattern, implement key pieces after designing them, then redesign as more parts of the system get implemented. I have never had a client where I could implement all at once as a grand expedition! It’s always been piecemeal implementation with design along the way, responding to changes in goals, site and emergent reality as the design goes into place. But having a big picture view, that is, an overall site design to at least a schematic level, is critical to help one work out where to begin the implementation. Then I would design the relevant patches, including their site prep and implementation strategies, and then proceed on the ground. Staking out is a critical part of the process! Field testing the design in reality, essentially (from a personal email communication received January 28, 2017)
This is an important comment, particularly given it comes from one of the most influential (if not the most influential) permaculture/ecological design process thinkers on the planet right now. For my current focus the most signifiant parts are:
having a big picture view, that is, an overall site design to at least a schematic level, is critical to help one work out where to begin the implementation.
In reality, I design the overall pattern, implement key pieces after designing them, then redesign as more parts of the system get implemented … It’s always been piecemeal implementation with design along the way, responding to changes in goals, site and emergent reality as the design goes into place
In terms of our shiny new continuum, while Dave’s book would, on a superficial reading at least, land him over on the left hand side, this more recent sharing of what he actually does in practice lands him squarely in the concept design up front then details emerge as you go or CDUFDDAYG camp.12
Earlier in this inquiry we shared Ben Falk’s statement that:
Master plans are not solid, set-in-stone documents–although everyone wants them to be. Heck, I am hired many times largely because people want a plan that’s solid, unwavering, and something they can follow now and in ten years. Sorry-they don’t exist. Most plans are iterative. And despite the authoritative sounding name, master plans are no exception. A good ‘master’ plan is a working plan-in other words, it’s the latest version of good approaches. It will change: that much is guaranteed. The important part to remember is that it’s a guide for next decisions, not an ultimate life map or site oracle. Land and the lives unfolding for them are far too complex, unpredictable, and mysterious for any vision of a ‘way’ to hold up year after year. (The Resilient Farm and Homestead, 2013, pp. 72-77)
Consider now his statement, in a 2013 podcast with interviewer Scott Man, that:
Although I make most of my living as a planner and site designer I am learning more every year the limits of that planning process and how inherently limiting it is. It carries a lot of power with it, carries a lot of weight, but most of the time too much weight. It’s easy to just take paper too seriously and have too many decisions based on what is or isn’t on a piece of paper. It can be great to guide overall decisions and to know starting points and know general steps but if it’s not coupled with the active hands on that constantly changes what’s on that paper master plan/site design it can be very misleading and very dangerous.
Ben’s words here display remarkable resonance with those we’ve shared of David Holmgren’s. Like David, Ben voices strong concerns with any kind of fabricating or CDDUF (concept and detailed design up front) approach. In particular, he hones in on CDDUF’s dangerous tendency to then influence implementation decisions such that the much more important reality of what is actually unfolding on the site gets overruled.
As far as the little diagram I’m developing here goes, these statements land Ben with David Holmgren. To me, this comment (from the same podcast) seals the deal:13
More and more every year I rely on the planning process as identifying general steps and starting points and trying to visualise … an idealisation of what a place might be in 10 -20 – 50 years, but really using the planning process to identify starting points and letting those starting points then organically drive the actions following those starting points.14
Let’s face it, Ben. You are an anti fabricator. You are at heart a generator, and you’re living and designing dangerously close to crossing the line and diving into pure CDDAYG:
Well this has been a bit of fun, I tell you. It is quite gratifying to simplify some aspect of complex reality into several pigeon holes then to casually slot respected senior colleagues and teachers in here or there.15
The upshot is this. Despite the idealised, linear CDDUF approach presented and modelled in all the published presentations of permaculture design process16 I am aware of (shown clearly in my review starting here), at least four of permaculture’s most well-known and/or cutting-edge design thinkers (including both co-originators) on examination either explicitly criticise this approach or don’t use it in practice!
This a striking internal contradiction within permaculture. Evidently thousands of people are being taught an approach to permaculture design (based on what is in the books) that some of the most considerate permaculture design thinkers in the world reject on the grounds that it doesn’t work!17
The design process authors and practitioners we’ve considered in this post, with a bit of extra research (David Holmgren, Ben Falk), email correspondence (Dave Jacke), and reading between the lines (Bill Mollison), advocate and/or practice entering the realm of implementation and active doing before a detailed design is completed.
We started this post with the seeming dichotomy between CDDUF or fabricating processes and CDDAYG or generating processes. Thanks initially to Bill Mollison, we found a middle path in CDUFDDAYG.18 At least in the sources we consulted, Bill Mollison and Dave Jacke espouse CDUFDDAYG (a fabricating-generating hybrid approach). So do David Holmgren and Ben Falk, though these two also show definite sympathies for CDDAYG. Hence the relative location of the four authors in my evolving little diagram:
So with CDUFDDAYG or a CDUFDDAYG-CDDAYG blend (namely the space inside the red line in the diagram) have we have arrived at a happy ending? Maybe. Maybe not. My feeling is we’d best let the dust settle and look around a little more before holding hands and dancing in a circle. I for one would like to see what others make of all this before getting too carried away.
That said, we’ve without doubt happened onto a promising development. With CDUFDDAYG (or this plus a dash of CDDAYG) we have an approach with scope to avoid both the rampant mistake making Alexander claims is unavoidable in CDDUF and the blindingly obvious concern that if you leap straight into CDDAYG that you’ll land in a mess of conflicts, major mistakes, and dead ends.19
Hmmm. Food for thought, hey? In the next post we’ll zoom out and see if we can find any guidance on these matters from the wider universe of design thinking and practice.
Meantime do tell me what you make of the continuum. Is it any use to you? Where do you sit in your design work, and are you on the move? If so, what is your trajectory? Do you agree that almost all publicly accessible presentations of permaculture design process are, on the surface of things at least, over in CDDUF land? Or can you share any documented examples of something different? Do you have any relevant quotations you’d be happy to share?
I really, really appreciate your comments. This stuff is written and shared in service of the global permaculture community, and in your comments I get valuable feedback as to how to that might be done better in future (not to mention motivation to continue!).
Once again a big thanks to James Andrews for feedback on this and all other posts in this inquiry.
- Thanks for the idea Paul!
- Dave Jacke has, in our private correspondence, and I’m sure publicly in at least one podcast somewhere (probably this one?), made the same observation. Indeed, that’s why he went on to develop a coherent design process and why it has been so influential in permaculture – it filled a gap
- And in doing so note the grand irony in Bill’s neglect of design process, given that the core of permaculture is design, and design is a process! This of course is not to in any way detract from the value of all the phenomenal topics Bill didn’t neglect
- Especially if plucked out of their context like this!
- In other places Bill has emphasised his preference to support owners in entering their own ongoing process, where design and implementation co-involve in a close embrace (rather than playing the expert consultant coming in from outside and laying it all out on paper up front). Here I invite any relevant quotes where Bill speaks to this matter. Please send them through for me to add or include in a comment below. I’m positive I’ve seen Bill somewhere saying something like “I sometimes think that the point of a design is just to get people started” – I would so love to know where that appears as for the life of me I can’t find it!
- The more perceptive of you might notice I’ve slipped contemporary mainstream architecture and landscape design in the CDDUF or fabricating camp (just to flesh things out a bit), which I can’t imagine anyone finding controversial.
- Which I was stoked to, at the eleventh hour and quite by coincidence, happen across while researching tree species for a design project a few days ago
- In terms of the review with which we started this current inquiry, it is interesting that David continues in the text immediately after this passage to note: “The planning process can be considered as a sequence of five steps:
- Inventory; the collection of relevant data.
- Evaluation; organising the data into comprehensible patterns.
- Strategy; the general direction and framework for development.
- Design; the particular forms which express the strategy.
- Management; processes of implementation and operation
Feedback at every stage is essential. Without this planning becomes a rigid ritual of no particular use. In fact, all steps occur to some extent simultaneously. For example, we usually have some notion of the strategy and even the management before all the data is in. Thus the planning process in practice involves the ordinary skills of responding effectively to the unpredictable and chaotic nature of reality.” (p. 21) – as we’ve seen (and will see more of below) this echoes a pattern we’ve seen with authors (such as Dave Jacke and Ben Falk), where there is a subtle disjunct between the earlier comments about master and strategic planning and then the presentation of an idealised linear sequence (despite the standard disclaimer re feedback). That said, David’s comment that “all steps occur to some extent simultaneously” does a lot to soften the ‘hardness’ of the linear example sequence
- Not to mention a bit later in the text saying: Thus the planning process in practice involves the ordinary skills of responding effectively to the unpredictable and chaotic nature of reality.
- namely that of the place he developed and continues to share with his partner Su
- David goes on here to note, interestingly, that “This does not mean that detailed plans and designs for houses or landscape are a waste of time. They are as essential as the preparedness to respond flexibly to new facts.”
- yes, to be exact he says get to a schematic design first but this doesn’t change the point – I’m using the phrase concept design broadly enough here for it to include what Dave means by schematic design – basically any whole-site design scheme, pattern or layout short of getting into details
- As does “site planning should be continuously fed by a never-ending process of analysing, interpreting, and acting” – The Resilient Farm and Homestead, p. 24
- Compare this with David Holmgren’s “Most importantly, strategy planning can help pinpoint the initial step to get the desired processes moving…. “
- I should stress, for the record, that these classifications are exploratory, tentative, playful, and based on the shared statements from each of the four permaculturalists reviewed. That is to say, what I have really been doing is placing their statements, not their entire (complex, multifaceted, and some times contradictory personages!) Right or wrong I trust those three of them still with us would agree this exercise has been a step toward clarity, even if that comes via this post prompting them to show how I have them all wrong!
- When explicitly or officially presented as permaculture design process
- See for instance this comment on the previous post or look around online to see examples of detailed permaculture designs being spat out in all directions as, presumably was recommended in the courses or books that got the designers started
- see diagram below for a reminder as to what the heck these acronyms all mean
- An example being Bret who had to move his shed after siting it prematurely
Loving the comments for this post! I’m an old permie with a PDC, and am training to be a SCRUM Master for an Agile team at my day job. One of the things that has always bothered me is people’s desire to get a PDC and then go create some static design that hasn’t gathered live data for multiple seasons, etc. The rule of thumb is to live on the land for at least one year in order to observe, but the desire to design usually takes precedent. I’ve also seen it go badly for folks who then want to apply their new PDC skills to paid projects for clients, without using an iterative approach.
I, for one, would love to create a prerequisite course to PDCs one day that teaches people how to observe over time and gather data, and how to iterate and create flexible components in permaculture designs, to change with circumstances, take advantage of antifragility, etc.
Thanks for the great thoughts and discussion!
Thanks Joy and I love your prereq course idea as well as the idea that these very things are deeply integrated into the PDCs of the future!
Thanks for this great series of posts !
I think the schematics called DesignProcessContinuum makes it very explicit there is a contradiction between what many designers thought they where doing and what they were actually doing.
I really appreciated how you take the time to gently make all this clear and explicit ! Making it explicit will certainly help permaculture become more popular and accessible !
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.
I discussed this in the paper I already sent you (https://www.academia.edu/14083615/Permaculture_Patterning_a_design_framework_for_systemic_transformation)
Developers using agile methods and design thinking practitioners have developed robust methods and I believe permaculture designers should look there for inspiration.
I also stumble upon Otto Sharmer Theory U and suggest you have a look. It is focussed on groups and human systems but share the same approach that other systems thinking methodologies used (Permaculture design, Alexander’s Pattern Language and generative sequences, Agile methods, design thinking) it could be an inspiration for permaculture design particularly on social systems.
Lastly I noticed the painter Friedensreich Hundertwasser seems to used the same kind of approach for his painting.
Hope all this inspires you to write more posts !
Huh, I didn’t know Hundertwasser was a painter; I know him as an architect. He seemed to be quite fond of the generative approach in his designs, particularly in the way he allowed found building materials to influence the form of his structures. Oh! More synergy! An architect using the generative approach to design (in my opinion) attractive, welcoming spaces for humans. Thank you for mentioning him!
My wife and I discovered his work when we went to New Zealand for our honeymoon. Behold the famous Hundertwasser Toilets of Kawakawa, NZ:
Thanks Lilian always good to hear from you. I better get the next two posts out quick because between Paul and yourself much of the content is being covered ahead of time! Thanks also for reminding me of your paper – I’ll link to it in one of the posts I’m alluding to. I will look up Otto Sharmer’s stuff also – thanks for the tip off. Most of all I’m pleased you’re finding the posts clear and explicit – this is a major aspiration for me – there is so much at stake and we’re talking about an approach (permaculture) with so much promise so let’s get our sh%t together as in get our assumptions about the core of our discipline (design) out on the table and weed out what’s weak or not working – especially when different parts of the same body of work (the PC literature) are saying different things about design process without even realising it!
Me again, with more thoughts on the intersection between permaculture and software design (specifically, Agile and Extreme Programming (XP) approaches).
That sounds like the Extreme Programming technique of working in ‘sprints’, or short cycles, each with a small list of completable tasks. The goal is to always deliver a working system at the end of each week/fortnight/month. It might not be complete and comfortable — your house might not have reticulated water yet, or your application might not let users log in yet — but at least the things that do exist are in working order.
There are a few benefits to working like this:
Smaller tasks are easier to reason about when it comes to time estimation.
When you order the highest-value tasks first, you’re leveraging your time and effort (the greatest change for the least effort).
You don’t get stuck in ‘analysis paralysis’. Your only goal is to this one task. Stuff gets done.
You can change directions quickly because you don’t have a bunch of half-finished things that are contingent on already-made decisions that you have to renege on.
In XP, the client is called the ‘product owner’. They take ultimate responsibility for the success of the project, which means they have to be knowledgeable about the problems they’re trying to solve. Part of this comes from their own competence; another part comes from the guidance of the designer-consultant.
I love the hybrid approach, AKA CDUFDDAYG. This one has the most promise, I think. Create a scaffold at first, into which your design-by-implementation bits can fit. It seems like it would avoid type 1 errors and the errors that come from making too many up-front assumptions. Maybe most of the effort in ‘strategic planning’, as Holmgren calls it, should be devoted to creating a sort of ‘DNA’ that guides every later decision to a desirable outcome, sort of like how Holistic Management works? It occurs to me that this is how organisms, ecosystems, and all complex dynamic systems work: they have a web of structural rules that tend to guarantee desirable outcomes given the right enveloping context. And a really good strategic plan might even contain the DNA required to modify parts of itself if they turn out to be sub-optimal:
I should add that this discussion isn’t merely a collection of abstract thought experiments for me. I’m facing my first real design project, a community garden and affordable-housing ‘pocket neighbourhood’ for a bunch of clients who don’t even exist yet. How’s that for tough? 😀
The thing I keep coming back to is, I can’t design something if I don’t know what the needs and constraints are. Maybe all we can design at the outset is some rules that will set the future stakeholders (i.e., owners/occupants and allotment tenants) on the right path for making their own decisions.
Thanks Paul for these reflections (and your other insightful comments) – I’m looking forward to your thoughts in a few post’s time when we’ll dedicate a post to exploring the Agile/XP approach – such relevant synergies for sure! I love the idea of a design process that not only enables the emerging design to be adaptive (via something like CDUFDDAYG with much generating and a minimum of fabricating) but enables itself to be adaptive, where the design process is able to redesign itself as required along the way.
It seems to me that XP’s “Metaphor” is in some ways equivalent to a goal articulation/high level concept – “Uber for cats” or whatever stupid software thing you’re making 😉 This is the conceptual guiding light that helps keep everyone on track. Also a pattern language – whether developed just for your project, or drawing on an existing one – can help keep all participants working in the same idiom. I really like this example of the first ever software design pattern language, which had only 5 patterns to describe a window-based piece of software back when windowed interfaces were the hip new thing:
As permies we don’t actually have a true pattern language to draw on (I have really wordy thoughts on this which I’ll share another time) but imagine if you could articulate the goal/metaphor and the pattern language or “idiom” for your design up front, then let the individual elements emerge. As each idea comes up, you can test it for fit against the metaphor and idiom, and if it doesn’t fit the design, you don’t do it (or, I suppose, you go back to the start and rework your high level concepts).
In some ways this reminds me of Dan’s posts elsewhere (eg. http://permaculturenews.org/2014/05/12/holistic-management-veg-part-three-putting-holistic-context-work/) about holistic management and testing your proposed actions against your holistic context to see if they fit. Dan, do you think if, instead of a Dave Jacke goal articulation, you did (or already had) a holistic context mapping and then iteratively applied the test questions to potential design elements, do you think you could do permaculture implementation as CDDAYG?
Hey again Alex. I agree that despite some promising steps in the right direction, “as permies we don’t actually have a true pattern language to draw on” as yet, though I look forward to learning more about where you’re coming from in saying this. To my knowledge Dave Jacke has come closest with his impressive start on a pattern language for edible forest gardening.
I’m excited when you say…
…for this comes dangerously close to the design practice I’m currently experimenting with, though I don’t tend to refer to elements much any more. As Alexander helped me see in The Timeless Way of Building, if you poke elements hard enough they actually themselves dissolve into patterns (I’d also be curious to see what you make of this post).
So in response to your question:
With the caveat re elements the answer is “yes!” (I would substitute “potential design/implementation moves” for “potential design elements”) – I now know for a fact that a CDDAYG approach along these lines (there are other nuances to it, of course, but this is indeed the overall gist) can work in a permaculture landscape development context, as I’ll share in an example later on in this inquiry (after first sharing some CDUFDDAYG action on a prior project – one step at a time and all that!).
There’s so much synergy going on here it’s making my brain hurt. I love how you pulled in Dan’s other article on HM, particularly how you pointed to the similarity between holistic context to a pattern language, namely, that they’re both processes to help you screen for idiomatic consistency. Never thought of it that way before!
Oh, thanks also for telling me about XP’s ‘Metaphor’; never heard of that one either. (Honestly a lot of my knowledge about XP has come from late-night baby-rocking sessions with the entirety of extremeprogramming.org loaded up on my phone, so I may have forgotten a few things 😀 ) Not only is this discussion helping me rethink permaculture design; it’s helping me rethink the way I do software development!
I was surprised by that simple pattern language for a windowed UI; I had no idea people got that high-level with their pattern languages. It strikes a contrast to what we call ‘design patterns’ like the Iterator pattern; it’s very design-focused.
While I agree with this guy’s feelings to an extent, I don’t think the software world has entirely gone off the rails re: our use of the word ‘pattern’. Some of what we call design patterns are quite Alexander-esque, because (a) they’re recurring solutions to problems, (b), they are telling us what to design, and (c) they often are connected together in a pattern language — although a lot more work could be done in this area, I’m sure.
For instance, I’d describe the five SOLID principles as a pattern language that describe the idiom of OO software and guide us to making the right decisions. They don’t specify any implementation details either, and they contain many smaller patterns inside themselves.
But I digress! This is totally not useful to the current discussion. It’s just fun chatting with a fellow geek.
One more point I wanted to make (and this really is germane to permaculture; I promise).
This really frustrates me. We have lots of patterns, from broad to narrow, from abstract to specific, and even the embryos of pattern languages here and there (or at least things that could be woven together to make a pattern language), but there doesn’t seem to be any place where they’re knit together in a cohesive whole. I would love to see a permaculture pattern language wiki come to life and really get some traction behind it.
I see the three ethics as the beginnings of a really simple pattern language. They relate to each other and create a theme. And Mollison himself said he didn’t invent them; he just recognised and articulated them. (Isn’t one of the criteria for a pattern that it must already exist?)
Couldn’t agree more about permaculture pattern language. It’s very scattered.
These are some selected bits from my notes on patterns/pattern languages:
WHAT IS A PATTERN LANGUAGE? (as opposed to patterns generally)
* a way of talking about design patterns
* it provides us with a SHARED VOCABULARY
* it connects patterns together, as words are connected in a sentence (structure/grammar)
* should be tailored to the DOMAIN
* though note that some patterns are cross-domain
* encapsulates advanced knowledge into something that novices can understand and use to design a system
* it must be used to communicate design ideas between people – otherwise it’s just a pattern catalog!
* languages are dynamic and evolve over time. people can add new terms to the language.
DOCUMENTING DESIGN PATTERNS (I’m basing this mostly on analysing how Alexander and the Gang of Four document their patterns)
GOOD PATTERN DOCUMENTATION
* Most useful when collected and organised from broad-scale to small-scale
* NAME the pattern
* Where is this pattern found? (context)
* Examples in the wild/how can you spot it/distinguishing features
* What problems does it solve?
* What resources does it require?
* What effects does it have (positive/negative) on other parts of the system?
* How does it connect to other patterns (patterns within patterns!)
* example: Alexander’s early “hypertext” linking between numbered patterns in APL
* How can you apply or replicate it?
* haphazard collection
* no recurrence – examples not patterns
* no memorable name
* lacks context
Great discussion above.
The following thoughts were brought into focus by a wwoofer responding to my description of a generating design process by saying “I would want to know exactly what my garden will look like and exactly what it will be producing.”
An undervalued ‘yield’ that is quite different to the products we focus on in our ‘permaculture’ domains (landscapes, social systems, building, education, health, finance), is to be in the ongoing design/decision making process.
A generating permaculture process that is connecting, observing, researching, experimenting, creative and satisfying.
An upfront design reduces this yield, hiring a ‘designer’ reduces this yield.
If a generating design/decision making process is ongoing then the ‘yields’ of being in this process are maximised.
As you say above Dan, ‘helping to dissolve human-nature separation (which I agree that in essence and aspiration permaculture is so much about’?
Love these thoughts Jason.
I’d like to share my Iterative Design Process with you:
I think it would fit pretty squarely under David Holmgren & Ben Falk as a CDUFDDAYG. I’ve been trying to approach my designing from this angle, not what is the whole plan but what’s the next move in context. I also give an example of the process in a softer setting, a social design for a collaborative work project.
Thanks for sharing Milton.
As I was reading your post I suddenly became aware of my own initial tinkering with gardening and then permaculture. Having been brought up in ‘the concrete’ as we say in Sweden, it truly took a long time to understand that not everything about nature can be understood from books. I like how you one time said that you spent a lot of your life developing your brain and only recently discovered that you have hands (and finally a heart!), and I think a lot of people in our generation can relate to the lack of understanding for nature and, even more dangerously, to having fear of nature. This is preventing even people who really want to become closer to nature from finding a useful way of achieving this aspiration. It is therefore, I think, it can feel so good to hire an authority like Ben Falk to give you a detailed design that you can follow, instead of diving into it yourself. We have become a society of experts, hiring other experts to do everything for us, from changing light bulbs to fixing our garden problems. Wendell Berry has written extensively about this in his wonderful book The Unsettling of America from 1978.
I feel like we have a special responsibility as active in the permaculture movement to erase the gap between nature and humans, and I sense that the design approach you are evolving towards is a useful tool in this endeavor. I’m sure you will share this later on, but how do clients respond to your approach? Do you have similar experiences to Ben Falk where clients want the finished product of your work to be a solid, unwavering master plan? And how do you respond to that?
Thanks again for doing this!
Thanks Alexander and right on! I hadn’t reflected on how hiring an external expert to help design and define your relationship with nature can so easily be self-defeating. It is a classic middle-person mentality – “I’ll talk to you (the expert), then you talk to the bit of nature out my back door, and then you tell me what it says”! Though this is not to deny the role that healthy process facilitation, including the sharing of such skills as reading landscape, can have in helping to dissolve human-nature separation (which I agree that in essence and aspiration permaculture is so much about). Yeah I’ll happily share some of my experiments in this direction with real clients in the coming posts.
One comment though is these days I’ll not take on a project where there is any expectation of a grand magnificent detailed plan up front. Any design client of mine has to demonstrate a reasonable degree of fluency in and desire for my approach before anything happens (In a sense I train my clients up first and then we only start a process if they pass the test ;-)). Actually there is a single recent exception to this, which has strongly reinforced the rule! I took on a large design project where all this wasn’t the case (Mostly because I wanted insider knowledge of how the large-scale development and architecture world actually works). And it has been hard work dealing with an industry-wide expectation that an incredibly detailed finished design for a roof-top garden and whatever else before the building or the roof even exists is a completely reasonable thing to ask for.
Hey Dan. Thanks for putting the energy into this series of posts they were a great read and well put together.
Two thoughts come to mind after this last post.
Firstly, that maybe we as designers have not realized that we can do more justice for clients educating them as a land manager and getting them started with a design direction as opposed to a detailed master plan; one that would include such details as plant types etc.
Secondly, I wonder if this issue with the design process is a result of the short term nature of the permaculture design education system. Of all the PDC’s I have done, they teach how to design, which is great. However, there is never enough time in the PDC to get PAST the how to design something (e.g. here is how we draw / digital design a food forest) to this place you have brought up which is questioning WHAT or HOW we should be designing.
One PDC I took was a 600 hour course, one of the most in depth I know of here in the states, yet it failed to even touch the idea of iterative CDUFDAYG design.
This series has put to words what I have thought was my struggle with permaculture design. I leave off with a greater feeling of confidence in what I am doing due to these posts. A tip of that hat to you sir.
Looking forward to more.
Hey thanks so much Bret. Great thoughts and it is affirming to hear these directions resonate. I’m grateful to be reminded there are many, many practicing permaculturalists around the world that a) have realised that what you might call permaculture’s centre-of-gravity treatment of design process has, well, issues, and b) haven’t yet left dejected, with a personal feeling that permaculture design has amounted to an unfulfilled or at least under-delivered promise. I’m excited at the thought of such folk connecting, sharing, and exploring what better pastures would look like, and, who knows, perhaps even collaboratively catalysing a gradual, gentle, but massively beneficial transformation of permaculture from within. Yikes, have I just unwittingly revealed an ulterior motive here? I’m not sure. Let the details emerge as we go along ;-). One thing is for sure though – with much appreciation for the occasional vote of confidence from folk like yourself – I’m not going to stop nibbling away out on the edge here anytime soon ;-).
ps. This particular inquiry is a long way from done – we’re probably not even half way!
Kinda like ‘Teach a man to fish and you’ll feed him for a lifetime’. But it takes a lot more humility, as well as the ability to let go of our desire to control outcomes. As designers, that can be hard, but as permaculture designers we should be well-practiced at that already 😉 Any attempt to control a complex dynamic system will likely result in failure, so we look for leverage points. Implanting the DNA of success in our client is one of those leverage points.
I wish there was an ‘edit’ button for previous comments 😀 That should be “permaculture designers“.
Hey Paul and happy to make edits if you send them through – just updated that for you. Alternatively if anyone is ever keen it also is I think possible to set you up as a site author or editor in a way where you’l be able to login and edit your comments. Let me know if you’d like me to check this out.
Hey, I for one would be interested. I’m always finding typos in my comments 😀
So letting everyone know I’ve set up a thing where you are able to edit (or delete) a comment you have just published for up to 30m at which point it is locked in. Let me know if that does the trick!