Completing a detailed design and then implementing it is not ideal in my experience. But in architecture there is no other option, at least where I live (Netherlands) because you need a building permit. And to get a permit you need a detailed design. There is hardly any space for change during the construction stage.
In permaculture we often have the luxury to keep on adjusting and tinkering. In all my permaculture projects we have made changes during the implementation. In reality you see things differently. And when you start using it perception changes again. Some things don’t work out as planned and need to be adjusted but you also see new possibilities. A design is never finished.
Thanks for your investigation of the design process. I’m looking forward to your next posts.
Legislation isn’t the only problem I see with doing iterative, constantly changing designs using the actual medium you’re implementing in. I have a hard time figuring out how to make this happen at all with architecture (would you tear down a wall and rebuild it slightly differently based on the feedback loops of usage patterns after a few years?) Dan promised he’s going to unpack that sort of problem in a future post; I’m looking forward to it eagerly!
Thanks Rutger and again to you Paul,
In a future post in this inquiry, after fleshing out and discussing the ideas a bit more, then sharing a few applications to a couple of real design projects, I plan to dedicate a post to exploring the issues and challenges a more agile, acorn-like approach presents, including the fact that an up-front detailed design is so often a legal requirement! You actually get penalised for trying to buck the BDUF! Another very common question I get is how do you make such an approach pay as a professional consultant. Anyway, we’ll get to such matters in due course, after having gotten clearer about ‘all the fuss’ is about.
Rutger your statement “In permaculture we often have the luxury to keep on adjusting and tinkering. In all my permaculture projects we have made changes during the implementation. In reality you see things differently. And when you start using it perception changes again. Some things don’t work out as planned and need to be adjusted but you also see new possibilities. A design is never finished.” really resonates. That said, I wonder if there has ever been a permaculture project where the implementers stuck to the initial plan, no matter what – surely a sure-fire recipe for project failure or at the very least a sub-par outcome…
I’m a software developer by day (permaculture designer wannabe on the weekends), and a lot of what you said resonates strongly with me. Over the past few decades, the software development world went through a similar set of discoveries — ‘Big Design Up Front’ (BDUF) didn’t work well because (a) it assumed too much about the client’s needs, (b) it wasn’t capable of changing its course quickly if client needs changed, and (c) it assumed that the expressed needs of the client truly were the real needs of the client.
Nowadays the darling software development methodology is called ‘Agile development’, expressed most succinctly in the Agile Manifesto http://agilemanifesto.org/ Design and implementation cycles happen regularly (typically somewhere between weekly and monthly), and the goal of each cycle is working software that meets real client needs. (Any given iteration might add anything from a few accounting-related functions that spit out the correct answers, up to a new user interface element that solves a recently discovered pain point for customers.)
The emphasis is on relationships with the client, solving the right problems, small iterations with tight feedback loops, nimble decision-making, and demonstrable results. Sound familiar? Sounds a bit like “integrate rather than segregate”, “articulate goals accurately”, “apply self-regulation and accept feedback”, “creatively use and respond to change”, and “obtain a yield”.
The early proponents of Agile were also big fans of Alexander; there are many pattern libraries available for programmers who don’t want to re-solve solved problems. They tend to be articulated in similar ways to Alexander’s patterns: state the problem, give a label to the pattern that solves the problem, then describe (in a general way that’s not tied to any programming language or architectural methodology) the ‘recipe’ of the pattern.
One mismatch that I see between agile software dev and permaculture is that agile typically just starts working on details and expects a cohesive design to emerge, whereas with permaculture we try to get the big design right to avoid any foundational errors. This is a bit of a caricature, I guess; a good agile developer is always thinking about patterns and overall architecture as they build individual elements. Still, it’s definitely a detail-to-pattern approach. Nevertheless, it tends to work quite well. An interesting side thought from a discipline which looks quite different on the surface but is actually quite similar.
One aspect of agile development that I find hard to relate to permaculture design is that there’s a strong emphasis on
Hm, it cut off my comment. What I was going to say is that with Agile, there’s a strong emphasis on getting into the details first and treating the design as an emergent property. Whereas in permaculture we talk a lot about working from pattern to detail, getting the basics right to avoid foundational errors. I’m caricaturing Agile a bit; any good Agile developer is always thinking about patterns (see above re: Alexander and software pattern libraries) and the overall architecture as they build individual elements.
Still, the emphasis is on building and connecting individual, self-contained elements. Despite the apparent lack of up-front design, this works surprisingly well, because (as the Agile axiom goes) you never know what you’re supposed to be building until you start building it. I think another reason it works so well is because of another Agile axiom: refactor (tweak/modify/rearchitect) mercilessly as your project grows.
Anyhow, just an interesting side thought from a discipline that seems unconnected but actually shares a lot with permaculture.
I’m a programmer too, and noticed some similar relationships between Pc design and Computer Science stuff. The main realisation for me is that design is searching through a space of possible solutions for something that’s reasonably optimal, so a lot of CS heuristics (particularly search, etc.) apply. I wrote up some of it here: http://neoluddic.tumblr.com/post/150212503801/permaculture-patterns
I would probably add that BDUF still works, it’s just suited to problems which you can nail down well, examples being space probes, car and plane software or life-critical things like medical equipment. I’m not sure how you’d get something like that in a Permaculture design – some sort of factory-style aquaponic or hydroponic system perhaps?
Anthony, I thoroughly enjoyed your blog post. It’s a fabulous contribution to the discussion, and judging by its publication date, you’ve been thinking about this for a while already. You echoed my feelings about element analysis, plus my frustration that permaculture doesn’t have a go-to pattern library like architecture and computer science do. Some resources do (the Big Black Book comes to mind, although most of its patterns seem to be appropriate for broad-acre and/or hot-climate applications).
Re: BDUF sometimes working, I’d add that sometimes Agile fails miserably. If the culture of your company or the clients is too brittle or bound up in politics, agile processes will be constantly hindered. If your client isn’t highly knowledgeable about their needs and how software might help them, and if they aren’t willing to take part in the decision-making, the project can turn into a mess in short order.
Hey Anthony and your comment reminds me I never got back to you about your thoughtful blog post as I intended to! Apologies and I have now at least added a link to it here though, and details (or elements) aside I love the idea of design process as a whittling down of solution space. It would be great to have a post exploring this more in future and I’ll actually think about working it into the current inquiry. Also that’s a good point about how BDUF is more appropriate in some domains than others.
Alexander(*) might note that the detail too holds information on patterns through recursiveness and the nesting of layers. In that case there is no contradiction whether starting out with the detail or the whole. The principles (or values) that guide the consecutive unfolding of the following steps is what is important.
As for the discussion on architects versus Matisse, I would rather state that architects are merely the canvas frame builders on which the life that takes on inside it is the ever changing paint. And yes – there are indeed weak and stronger canvas builders. Good building are open to change (embedded robustness & resilience) and bad buildings are simply torn down. That is why often old buildings, the survivors of this process of selection, are so loved.
As for designing by doing or by premeditation (‘drawing board”) I know from experience you really need both. It’s the issue of complicated versus complex: components level versus system level. It’s wise on component level to at least design an infra structure or set of governing rules (or you wast a lot of resources fixing conflicts). As for designing on the system level, I believe more and more people are slowly becoming aware how buildings fit into the larger system and what this implicates for the design.
Hey Gerald and I love your comments! Only thing I’m not sure about is the word “merely” in that assumptions and decisions go into the making of any canvas that direct / constrain /shape what is possible come painting time and often tearing a building down only happens after many years of unnecessarily compromised living. But as you say that’s why it’s important to be able to distinguish between weak and strong canvas builders! I really like Stuart Brand’s How Buildings Learn work on this topic. In one episode of the documentary series he made after the book he looks at a project of Alexander’s and points out that there not only is the building able to change/evolves once built, but the process of building it is wide open to change in a degree unusual for modern architecture (due to the way that premeditation and doing are intertwined).
I’d love to explore your first paragraph more some time (it is a pocket of densely concentrated insight!) and your last paragraph is awesome and super relevant to where this is heading – I suspect I’ll be quoting you in due course.
Thanks again for chiming in.
Oh, apparently it didn’t cut my original comment off; I just left an unedited bit at the end. Ha! I feel like my second try was better anyway.
Hey Paul and thanks so much for commenting! Hopefully others will follow your fine example ;-). I’m excited to read your rich reflections on agile and some of the synergies and dissonances with permaculture. I dipped into agile a few weeks back as part of research for this inquiry and was quite amazed at its relevance. I plan to share and develop some of those dippings in a few post’s time, which will now be enriched by weaving your reflections in, and, I hope, having your input again at that stage (ooooh – this inquiry is itself getting a little taste of agile goin’ on!). What fascinates me is that software development confronted and traced the implications of this stuff out (as you say with a little help from Mr Alexander – you stole my thunder there but all good, I can share ;-)) long ago, yet as you hint in your reply to Rutger the way it rolls out for permaculture will be different even if stemming from the same realisation – BDUF just ain’t cool.
ps. You mightn’t have noticed but coincidentally the url www.agilepermaculture.com was also registered a few weeks back. Fancy that!
Fantastic work Dan, your visual diagrams capture the multiple layers of thinking that are closer to life than text description can. I have found your ‘the permaculture tree (take three)’ to be very useful in this way also.
I am keen to jump in to the conversation here, I have some catching up to do! I am not a big reader but am actively involved in design facilitation professionally in Dunedin.
For me I think we place a lot of emphasis on the drawn image, as James Andrews says, they are seducing, and power given to them with labels such as “Project Masterplan”. When in reality a plan is a fraction of the relationship and hopefully learning journey between client and ‘designer’. There is also conversation, time spent on the land together, shared resources, shared examples and inspiration, project descriptions in writing, management plans etc.
If I have time I would share a project process with you by putting your fabricating diagram on top of the generating diagram as that is how I see that this particular project played out. To be clear, I offer this as an example, without attachment, I’d love to hear what you think.
I meet with clients for a couple of hours to 1: listen, to their dreams, ideas, wishes and their observations of the site. 2: carry out my own site assessment. 3: Provide as many resources to them for their benefit. 4. to offer my services (they chose a “concept plan”.
I usually jam out initial ideas as soon as I get home. Then Draw up a detailed base plan. Then spend a week playing with layouts on paper using as many design methods as I can.
I return to the property and test the layouts on the ground with bamboo stakes. Walking through, testing heights, the feel etc. Re sketch and then meet with the clients again to walk around and talk through my ideas so far and hear their thoughts in the mean time. This can happen a few times if there is much to resolve.
I then produced a concept layout Here is the concept planting plan for this project, there was also a concept landscaping plan
They liked it and asked for an estimate to build. This required me to sketch details for costing, some, such as the pergola design, I ran by them. We negotiated, removed some details and booked in the excavator.
This perhaps brings us to the large spade at the bottom of the fabricating diagram?
Excavation finds shallow rock!, therefore concept Macro retaining is not possible, but we have lots of rock! Overnight I sketch an image of what a stone wall would look like instead. The clients like it, and we replace one stair with a seat in the wall instead.
Many more such discussions along the way… paths become curved instead of square along the way, the rear lawn becomes round and after grass is installed there they use it and request paver stepping stones within it, so we install those.
Importantly I think, the planting plan is never fully drawn, just sketched to enough detail and approved AFTER hard landscape is complete, in order to buy plants. Final layout is on the ground on the planting day. Plants are my favourite part, why I do this, and I find that layout with them in hand is much, much better than on paper!
Conclusion: This was a very nice project to work on, where there was enough trust and good communication that it could evolve as construction was done. A ‘concept plan’ was completed, this gave enough detail and ‘feeling’ to allow pricing and confidence for the client to go ahead.
The Making Permaculture Stronger conversation is giving me give descriptive language for and perception of the times when I feel that working on a project goes well. This will be of benefit for future projects in describing how a project may unfold to a client and letting go of the sometimes taxing pressure on myself to come up with Detailed Design when the time isnt right.
Where does fabricating and generating sit in this example do you think?
This was a very nice project to work on, where there was enough trust and good communication that it could evolve as construction was done.
From my experience with software design, this is one of the key elements (maybe the key element) that makes iterative/generative/CDDAYG design work. Communication and trust. Without communication, the outcomes can vary so much from the expectations that the client can get quite disappointed. Without trust, it’s hard to pitch the idea of incremental design with room for changes in direction (the client thinks you must be incompetent because you can’t come up with a set-in-stone plan).
Hey Jason and thanks for sharing and I’m excited to be entering the territory of others sharing real-life design process examples – obviously enormously helpful in seeing how the ideas we’re discussing do or don’t apply. Makes me wonder about a better format for facilitating such sharing. Anyone got any ideas?
Your mention of putting the fabricating diagram on top of the generating diagram is most interesting given it’s part of the territory I’ll explore in the upcoming post! I think your example is of this nature. You did a bit of tentative fabrication then the site was most helpful when the submerged rock said “Hey buddy and guess what – it’s generation time.” It reminds me of the very similar example David Holmgren gave when I first discussed the fabricating (imposition) vs generating (unfolding) process distinction with him. He designed his house (off site, sitting in his Melbourne share house) in a lot of detail, including the detail of where it would site on the site. Then site prep started and a rock reef said “uh ah bulldozer – this is as far as you go.” And so the house moved a few metres to accommodate the reality of what was going on. Then he gave the contrasting example of the barn, which was highly generated. To cut a long story short they noticed they were stockpiling materials at a certain spot and so they built a roof over that spot.
I’m also delighted if these discussions help relieve the pressure that you or I or anyone else can sometimes feel when clients expect you to pull a detailed design out of thin air (when as you imply in reality if you explain the folly in this, the fact that you’ll often times being doing them a disservice in opening the door to a bunch of premature and arbitrary decisions, they are fine to wait!).
Finally that’s great to be reminded how you use bamboo stakes to mark out as part of your design process.
Another programmer here chiming in – a common theme eh?
I definitely see and have experienced both sides of this argument.
In instances I absolutely had to have a design ahead of time to even get a grasp of the “whole” project. In this case I am thinking of a series of earthworks I did a recent install on. If I had just jumped in I really do think it would have been a mess.
However, while the design did help get things going in the the right direction (especially with something more on the permanent side such as earthworks), it was not as good as it could have been. The feedback loop showed issues, weaknesses in my my design that my eyes did not pick up on during the process of observing and translating that to designs.
In other instances I just ran with what I wanted to (on a whim) without a design, starting smaller and making adjustments as I go. Sometimes this worked out well other times it meant major issues. In one instance I built a 250 sq ft shed 90% complete and decided it was in the wrong spot for the site. Took it apart and pulled it about 600 feet down the hill to a new location.
Such experiences leave me seeing how us humans do not work as nature does but can benefit from her methodologies. Her unfolding is based off a pattern that failed or succeeded over millions of years developing a refined pattern that often produces the most efficient and beneficial outcome.
How us humans can condense this down into a lifetime, or better yet, a few years to design and develop a homestead is where I leave off with questions.
I see how permaculture designs that I do are my best attempt yet in the larger picture still half baked. Every design that is executed leads to more experience and knowledge to better inform the next. I suppose this is in fact mimicking mother natures long term process of natural selection in a way.
Struggles of being a human trying to mimic and understand nature aside, I remain open to learn from her and improve / refine the permaculture practice.
Hey thanks for sharing Bret! These kinds of real-life examples (grit and all) are just invaluable, and your humility is encouraging (and sometimes a sorely missing ingredient in permaculture design examples where the grit tends to get ironed out in the retelling ;-)). Your comment nicely captures the desire for any appropriate design process to both avoid rushing in and making big mistakes due to a lack of appropriate planning (moving large sheds is hard work!) as well as being adaptive / real feedback rich enough so as to not have the opposite kind of mistakes happen – where the loud voice of a pre-formed plan shouts (or bulldozes) so loud that the whispers of what’s actually happening on the ground don’t get heard and responded to. I sure don’t have the answer but I do look forward in a few posts time to sharing some real-life attempts at finding the sweet spot where what happened was, at the least, a huge improvement over the more standard approach I’ve taken in many hundreds of previous design projects (and don’t get me started on the grit therein!).
Thanks Dan. Looking forward to seeing some examples of how this would look comparing a traditional fabricated design to a generated design and how to get a client on board with not getting big picture master plan as they so often want.
Me too Bret ;-). Not too long to wait now, I promise. Besides if I build any more suspense it’ll probably be a let down ;-).
Dan, thanks for working through this so thoroughly! I feel like a child opening the next door in an advent calendar when there is a new post here (how much longer to Christmas?).
Ever since I took my PDC and one of the teachers said she’d rather teach people permaculture than design there properties, I have felt like permaculture can do better than fly-in fly-out designers worshiped as rock stars. The way I feel designing works best for me is by being a gardener rather than a designer. The drawing and plant research happens between my fortnightly visits and the design unfolds while pulling weeds and mowing lawns.
Good one Alexander and though I’m not ready to fix a date for christmas I do hope you’re going to like your present ;-). I like the way you describe your approach.
I have found playing with bamboo onsite to be extremely productive. It is only possible on a fairly clear site. It works really well as a collaborative process with others (and for reality checking my own ideas). It allows quick mark outs of beds, trees (to exact height if you have long bamboo) and the corners of structure for example (string can be added to ‘solidify’ lines. We then walk around and feel out what it is like, adjustments can be quickly made. In some cases that is all that is needed, stakes are left in place, or sketches made allowing written detail to be attached.
It is a kind of drawing on the land, a step closer to doing than drawing on paper.
Having said that I do love drawing, and find that beneficial patterns emerge in the more abstract drawing process, patterns difficult to recognise on the ground. Drawing engages the eye, body, memory of the place and if spontaneous stimulates connecting ideas.
Insightful inquiries Dan. Since Jason raised my attention to this website a week ago I have been feverishly reading each post to catch up. It is certainly curious that esteemed permaculture authors have not acknowledged Alexander’s critique of their core understanding of design…
I was certainly taught design by fabrication on my PDC. As you have shown it has become an ingrained and almost expected approach to permaculture design. What I read here resonates with how I have come to approach designs i.e by generating, by differentiation. To me design by generation is the ‘natural’ approach. Logical even. Practical certainly. Each decision once implemented changes the ‘whole’ and almost always forces one to look again at that whole and differentiate the new whole. Design -> Implement -> Evaluate -> around it goes for each element/decision. Your graphic of the Permaculture Design Process illustrates this.
I look forward to reading where this all goes…
Thanks Nick and that’s all great to hear/know especially that it rings true both with what you were taught and what resonates better with what you’ve come to. The next post will drop tomorrow – happy reading and do comment again!
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.
[…] maybe we as designers have not realized that we can do more justice for clients educating them as a land manager
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.
[…] but as permaculture we should […]
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!
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!
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.
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.
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.
Me again, with more thoughts on the intersection between permaculture and software design (specifically, Agile and Extreme Programming (XP) approaches).
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.
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 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
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.
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:
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. […] it’s a guide for next decisions […]
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?
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).
As permies we don’t actually have a true pattern language to draw on […]
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
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…
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)
…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:
Dan, do you think if… 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?
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!).
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.
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 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 !
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!
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 for all your work here… it’s really helping in shaping my thinking/feeling in this space. One thought that I keep coming back to, pertains to the utility of the ‘permaculture garden/property/house’ as the focus of design (whether adaptive or linear). Is it possible that the metaphor of a garden as ‘permanent culture’ has reached its maximum utility within the permaculture ‘philosophy’ (and I use that word intentionally) i.e has permaculture outgrown the garden/property-design-on-paper as a ‘product’ that designers aim to ‘deliver’. Aren’t we really trying to co-create sustainable, adaptive and flourishing human culture on this(our) planet?
If we accept this – then the process of ‘design’ as it currently stands needs to be turned on it’s head (as Christopher Alexander and you eloquently argue). I think it is much easier to accept an adaptive, evolving design / implementation process if we are talking at the much broader level of human/community functioning than it is to try and squish it back into a garden design…
My thoughts on this topic turned to thinking about other groups or professionals who intentionally design or ‘meddle’ in large scale human and ecological functioning. Some interesting models might be worth looking at within the military (scarily enough) – OODA loops, adaptive campaigning, effect based operations are all methodologies aimed at shaping ‘design’ towards certain states of human existence (not necessarily positive of course), but that doesn’t remove the possibility of looking at the design/implementation model as having utility within Permaculture. Another group would be my own profession (Psychologist) where we are ostensibly asked to help ‘redesign’ people’s lives to make them happier / well / flourish. Of course given the complex and unpredictable nature of human behaviour and the multitude of interaction effects with each individual’s environment, it is almost impossible to design any ‘outcome’ – rather it become an iterative, co-designed, co-implemented model of adaptation. An example of this co-design is the note taking methodology (SOAP) – which stands for Subjective – what is the client’s present experience, Objective – what does the clinician know is factual, Assessment – what is the best summation of those two points (often referring to a external ‘broad’ guide here – in this case a diagnostic manual), and Plan – what is the first (mutually agreed) action step to move forward.
Anywho… some more food for thought…
Hey Mark and your comments are in turn helping in shaping my thinking/feeling (I felt happy to see the word “feeling” in there BTW). I agree re what we’re trying to do yet I’m undecided about whether I find it easier to think of design in evolving/agile/adaptive terms for a particular property/site or at the broader level of human/community functioning. It feels a bit chicken and egg in that all human community functioning is (ultimately, the internet aside) anchored in and deeply affected by the character of pockets of space (at whatever scale), while the ability of those pockets to support healthy community functioning and evolutions depends in some large degree on how healthily the community was functioning in the processes of shaping their character! Possibly another both-and rather than either/or situation I’m musing.
Food for thought indeed and thanks for the references to other models. If anyone out there is scratching their head about what to do their PhD thesis on then scratch no more ;-).
Some exciting developments in this inquiry! As Anthony Briggs says, waterfall/BDUF does work — for certain problems. His words:
It’s just suited to problems which you can nail down well […]
It seems to work best for problems with well-established solutions, which I’ve found to be few and far between in both software and permaculture. Well, I shouldn’t say that — there are plenty of them within a project; for those, we pull a pattern out of our library and implement/integrate it.
This, I think, is the chief failing of the Rational Model:
[…] goals are often unknown when a design project begins, and the requirements and constraints continue to change.
It’s all about brittle assumptions. All design is assumptions, but the difference is that in the Action-Centric Model, you test those assumptions early and change course if needed. ‘Fail fast’ is a popular mantra in software product design.
Let’s say you set out to design a project management app. You might think that designing a better, more featureful task creation form is what your customers want. But then you build that form and find that it frustrates customers. It might’ve been that they thought they needed more features but actually they needed fewer. Or maybe they needed a way to create tasks via e-mail, because they don’t get this newfangled web app stuff.
If you’ve spent all this time writing up a functional requirements document, creating a pixel-perfect mockup, then implementing it in code and rolling it out to all your customers (waterfall/BDUF) you’ve wasted a lot of time. If, instead, you start with some really rough prototypes and test them with a small group of users, you’ve wasted very little time. (Some software designers just use pieces of paper for their prototyping!)
This won’t catch all the problems with your design (cf. Christopher Alexander’s warning about doing your design in a different medium from the finished product) but it has the potential to steer you away from some huge type 1 errors, and hey, it’s cheap!
The moral of the story, I guess, is to identify the leverage points in your design path — the decisions that have the biggest potential positive or negative impact on the success of your project — and think up ways to test them super early and cheaply.
There are other great things about the iterative/incremental/agile/fail-fast approach, but I’ll save my thoughts for part 8! 🙂
Thanks Paul and love your statement “It’s all about brittle assumptions. All design is assumptions, but the difference is that in the Action-Centric Model, you test those assumptions early and change course if needed. ‘Fail fast’ is a popular mantra in software product design” not mention the moral of the story. Right on!
Thank you for this post – GREAT timing! I’ve been thinking about this stuff a lot lately.
I actually came to Permaculture via Christopher Alexander, after hearing about design patterns in a software engineering course in the mid 1990s. Although I’ve hung around the edges of Permaculture since then, I haven’t done a PDC in part because the impression I got (largely through Mollison’s Permaculture Designers Manual) was that the design methodology was haphazard – at least compared to what I was seeing in my software engineering work at the time. When I heard that a lot of permaculturists had started to pick up some design rigour from Dave Jacke’s work, I started to get interested, googled “dave jacke design methodology”, read a bunch of your posts, and to cut a long story short I’m currently in the middle of a PDC that’s running over several weekends in the first half of this year.
At the moment the PDC is going deep into Jacke’s process, so imagine my surprise when I found out that his method is basically the “waterfall model” of software development that I learned in the early 1990s – though even then it was taught with the caveat that it was already outdated and mostly to be found in big, old, slow-moving organisations like banks or the military.
So I spent a chunk of this weekend, as my PDC covered Dave Jacke’s design methodology, wondering:
– will Jacke’s method have the same problems and failure modes, in time, as waterfall software development?
– what relationship do methodologies such as agile, XP, rapid prototyping, lean software development, etc have to permaculture?
– does the inherent “cycle” of nature – the year – mean that the rapid releases and quick feedback of agile development don’t work in land-based permaculture? What about in non-land-based, such as social permaculture?
– how do the agile manifesto, agile principles, and the 12 practices of XP map to the permaculture ethics and principles? what’s missing on each side?
I came home from the PDC and googled “agile permaculture” and there was your post – very timely! I’m delighted to be able to point people at it, as you express it much more clearly than I’m able to – I keep relapsing into incomprehensible handwaving and nerd-speak.
Btw the original book “Extreme Programming Explained” by Kent Beck et al has a fantastic diagram of the 12 XP practices with arrows between them showing how practices support each other. Eg. “automated testing” supports “continuous integration” which in turn supports “short release cycles”. Here’s the pic online: https://ullizee.files.wordpress.com/2009/11/kent-beck-12-xp-practices.jpg … What struck me is that if you remove any of those pieces, the whole mutually supportive network starts to collapse. (Incidentally I believe this has happened in modern agile vs the more idealistic XP as it was 15+ years ago; XP had a much stronger focus on “people care”, which I think was watered down in recent years to make it more corporate-friendly. But that’s an aside.) I’d love to see a similar diagram done of permaculture principles, either in general or in their application to a particular project, to show that all the principles are in play and are supporting each other. Much like having each element in a design fulfil 2+ needs/having 2+ elements to fulfil each need, you could ensure that each principle is in play in 2+ places and that each element demonstrates 2+ principles. Drawing a diagram of them would clearly show any outliers that weren’t strongly connected.
On another note, a few weeks ago I went down a pattern rabbit hole, reflecting on pattern languages from Alexander to the “Gang of Four” with their software design patterns in the 90s. Along the way I found this presentation given to a software conference, which I think has a lot of application to permaculture and how permaculturists talk about “patterns” and “pattern language”: http://perl.plover.com/yak/design/ – I’d be very interested to know what you think (and if you’re interested, I have a longish set of notes synthesising what i know about patterns from Alexander, software eng, textile design(!!!) and permaculture which I could share by email).
Thanks again for this post and for making us all exercise our brains in making permaculture stronger.
Greetings Alex and what a delicious comment!
As I explored in this post and as I know from having the pleasure of seeing him at work, in practice Dave Jacke uses a process more adaptive/generative than some of those reading and teaching from his book (EFGVII) might realise. Dave has also mentioned to me that his design approach has evolved a lot since the book was written and I look forward to him publishing an update or speaking to these evolutions on a podcast or some such in future. As these comments likely reflect (see also this post), I have nothing but deep gratitude and respect for Dave Jacke’s enormous contribution toward permaculture getting its design process shit together.
Re principles I’ve been keen for a while to get myself clearer on the relations amongst permaculture principles possibly including the sort of networked approach in Kent’s diagram (I hope to progress this during this event).
Speaking of XP asides another one I came across is that, ironically, the most prominent aspect of permaculture I’ve seen Kent Beck noting appreciatively is the idea of design as element assembly, which I think must work well in software design, but which as I explored in the previous inquiry, can create problems in the permaculture context he lifted it from!
I love the punch line of that presentation you linked – DAMNED STRAIGHT WE DO! Reminds me of a youtube of a talk Alexander gave to software developers where as I recall the punch line was something like “don’t just appreciate my process innovations, appreciate what those innovations were in service of” (Alexander’s career-long quest to help bring the real physical world back to life).
And I’d love to see your notes – please do send them through (info at this website’s url or use the contact page and I’ll reply).
Augh, WordPress just ate my comment! And now it’s complaining about duplicates and uuuughhh. Please ignore this paragraph, it’s just here to let me post the same comment again.
I was going to say, Kent Beck is maybe being a bit misleading about element assembly, because it’s not anywhere near as haphazard as it sounds.
In XP, there is a “metaphor” which is a high level articulation of the overall concept, and then software developers tend to work from broad scale to small scale within a session of work. For instance, you decide:
* what overall design concept works for this problem
* what elements fit together to solve it
* how they communicate
* how each element works internally
… and then apply the same process at a smaller scale as you get down to patterns-within-patterns. In fact, in software testing, the process of “test driven development” says that for even tiny bits of code, just a few lines, you write a test FIRST, then see if your code passes the test. That’s actually goal articulation at the micro level.
There are also other practices such as “spikes”, which in XP are when you say “look, there’s 3 potential ways to solve this, let’s spend a day experimenting and see which one works best.”
On top of that, XP’s reliance on the onsite customer and pair programming mean that everything you do is constantly peer reviewed and seen through multiple sets of eyes, who tend to ask questions like “why did you…?” and “what if…?”
And then, automated testing and continuous integration mean that if you make a mistake, you’ll know about it instantly.
Permaculture doesn’t have the toolchain that software development does (stuff like automated testing software, rapid deployment, refactoring aids, etc) but imagine if it did! My mind is going to a really fascinating future.
Thanks Alex and great to hear more about XP – I hope to pick up on some of these threads come “rubber-hits-the-road” (or better in this context to say “spade-hits-the-ground”) time in this inquiry.
One can only endure a cliffhanger for so long! We’re waiting… 🙂
Thanks Alexander and sorry to keep you hanging! Life actually has become a little full the last few weeks, but I’m hoping to free up some writing time next week to get this flowing again, for I’m still itching for action!
Looking forward to it!
“does this relative irreversibility in changing the physical (as opposed to a virtual) landscape require a whole-site concept design up front?”
Does Agile works only because it deals with digital elements ?
It’s worth mentioning that Extreme Programming and Agile methodologies influenced the design and building of Wikispeed, an open source car.
This gave birth to Extreme Manufacturing (XM: https://en.wikipedia.org/wiki/EXtreme_Manufacturing) a method to design physical objects/machine.
To understand better the principles of XM, I collected principles and hope to generate patterns from them:
So it seems likely XM and Alexander’s methods (such as the ones used to build a whole university campus and described in “The battle for the life and beauty of the earth”) could be adapted for large projects such as the ones permaculture deals with.
Thanks again for writing all this so comprehensively, it helps a lot !
Thanks Lilian look forward to checking out these links!
The addition of Chaos to the generating end of the spectrum is useful.
You say “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”. This confusion is certainly true in the conversations that I have had on the subject. Where I find that there is a fear of loss of control over a desirable/productive/orderly end product.
Whereas we as Permaculture designers (decision makers) perhaps we are wanting to push the boundaries of design, to be in the creative flow of responsive decision making. To allow for the unknown to enter. For new solutions/patterns to emerge, co-created with nature. To not claim that we can create a functional ecosystem, and yet bring about a process of evolution from which we hope that one will unfold.
Chaos should be recognised as a theoretical end of the spectrum, as we all, in anything we do bring some sort of patterning/culture/research/overall vision/decision making to what we do, even when we “run around in circles digging holes faster than we can fill them in again”.
For me this kind of chao you refer to occurs either when I am rushed, or acting within a collaboration (or with myself) where there is some sort of communication block, tensions, or such reason that makes the design/decision making process dysfunctional. The results are never satisfying or exciting!
So, that’s me saying, yes, lets keep focus to the left of chaos in your diagram
Thanks for this Jason. Love your para starting “Whereas we…” btw!
Good to have you back Dan!
I agree that this is a very helpful addition for anyone who wants to claim they’re implementing a design in the spirit of CDDAYG, and to distinguish that from the situation where feedback is not accepted and processed as a part of implementation (ie chaos). Ben Falk talks about how he learned more about the land in one year of planting trees, than in three years of passive observation (I believe it’s in the permaculture voices podcast you referred to previously). Surely you could learn heaps from chaotic planting and digging holes, but there has to be a feedback loop.
I’m wonder if RIGNCD should be a singularity rather than a spectrum. Once you have stepped over the line (that you indicate with the dashed demarcation) from CDDAYG to RIGNCD, then you’re in chaos. Can you go further into chaos?
I’m also interested in the boundary conditions for chaos and if there are some clear signs for the demarcation.
Thanks Alexander and you’ll see I’ve since moved away from using the term “chaos” in part to make the thing more clearly a continuum (of process arbitrariness and as a result system adaptedness).
Isn’t it lack of awareness and not complete chaos that you’re talking about here? I would put chaos two squares to the left of CDDUF with RIGNCD inbetween. Then the chart would be a spectrum.
Intention is another thing entirely…
Great thought Milton and you’ll see I have taken your suggestion on board (in my own special way) and moved RIGNCD across to the left (and also retagged it WI) and dropped the term chaos from the situation for now. Also re intention have made it clearer where that is present/absent.
I kept thinking, what could start out as a RIGNCD could metamorphose into a CDDAYG if a feedback loop exists. Also, CDDUF would probably morph into CDUFDDAYG as reality exerts itself on the design.
Right on Milton. I remember many occasions in the past when the CDDUF approach I used to use got sort of salvaged toward a better outcome than would have otherwise happened by the fact that I managed an extended implementation process which forced me (reluctantly at first!) into CDUFDDAYG. I also agree that it is possible for something that starts out as what I’m now calling “Winging it” to morph into CDUFDDAYG if feedback kicks in / bites back hard enough, though I’ve personally come across very few cases of this. It is hard to teach an old dog new tricks and winging it is getting to be quite an old dog ;-).
As recently discussed, I’m not so sure that RIGNCD forms part of the spectrum of design (or facilitation for that matter). For me, the two are differentiated by a) the concept of ‘conciousness’ and b) the concept of ‘meaning’.
What I mean here is that for something to be a ‘design’ or a ‘design process’ requires that it is a consciously intentional process. In the first three concept of design, a ‘designer’ attempts to facilitate or create an outcome that is in accordance with the permaculture ethics and principles. In your fourth concept, there is no ‘conscious’ design and hence the outcome is highly unlikely to fit within the bounds of permaculture principles and ethics (given that there is a chance that it may). Secondly, and interwoven with this, is the necessity for a ‘meaningful’ order to be the outcome of design. Again, a subconscious design methodology is unlikely to create a meaningful order, at least in so much as it falls within the Permaculture Ethics and Principles.
Having said all this, I still think (as a behavioural psychologist) that even as a subconscious design process there is still likely to be some meaningful order represented in the design. Humans create things that fit within their mental models of the world (consciously or not)… so in that sense, the many examples of architecture and home gardens designed ‘piecemeal’ will in a sense be representative of the ‘patterns’ held subconsciously in the mind. There is an opportunity to observe and learn here – what are the patterns that are generated when design is subconscious and representative of the dominant culture? We could learn quite a bit about the mental models held by mainstream culture by looking for the patterns represented here….
Finally, I do also want to balance the logic of using ‘conscious design’ and ‘meaningful order’ against the more eastern concepts of ‘flow’ and ‘mushin’… In reading some of Christopher Alexander’s work I do think he proposes that the more advanced philosophical aspects of design become a living process that unfolds…. much of which incorporates emotion, and sensing, rather than purely logic or intent. In this way, design perhaps becomes more of an artform rather than just a science, couched within universal ethics and principles that provide the ‘edges’ or boundaries that mimic those laws created by nature….
Thanks Mark and yep great first point – which I hope is addressed in the above update by the clear differentiation between cases where there is or isn’t an intentional design process in the mix. Yep I also agree that there is much to be gleaned re dominant culture / mental models from the actual patterns we are creating – “as within, as without” and all that (though going too far into this mindset can make a walk down the street a rather demoralising experience!). Your last point is appreciated too, in that in my (early) experience logic and intent need to be complemented by emotion and sensing (or maybe vice versa is more accurate) in order to generate deeply adapted systems via CDUFDDAYG/CDDAYG. I think there is false dichotomy between art and science that starts dissolving inside the right-hand end of the updated continuum.
I feel like the RIGNCD is important to recognize as an approach even though it is not by definition any sort of intended design. The value in RIGNCD is purely experimental and therefore getting outside of the box of design; which can be good or bad depending on the result vs the intended (if any) outcome.
Hey Bret and yep true that.
Hello, hey I’ve just been looking at that diagrammatic contraption you’ve got there and whilst liking the increase in representativeness that the all new RIGCND category brings, I find myself faintly offended by its proximity to the generative end of the spectrum.
I understand that, (as Jason mentioned) conversations that explore the potentials of more generative approaches can evoke fear of the chaos, but does that fear come just because we are getting a bit far from our cultural comfort zone (CDDUF) and are starting to have a mild panic attack, or is it actually true that the generative approach if taken to its extreme, risks becoming chaotic and random? And is that risk of chaos greater at the generated end or the fabricated?
Could RGCND be moved to the fabricating end of the diagram? Or should it be split in two where its dangers exist at either extreme? OR maybe the fabricating/generating spectrum is a stand alone thing that hovers above the chaos, which is like a shark tank underneath, into which you risk falling if you go off either end?!
James Andrews! Fancy meeting you here! (I’ve been trying to lure James into this more public end of the conversation for months ;-)). As discussed (in person) we reached this same feeling of faint offence independently and both feel good about it’s relocation to the fabricating or arbitrary / impositional end of the spectrum (not to mention its renaming).
Alex has had some of these conversations with me and I’m also very grateful for your post on the possible links between Agile & ‘traditional’ permaculture design. It’s an exciting conversation with a lot more to be learned by the permaculture community, I suspect. (I’m teaching the design component on Alex’s PDC so she’s keeping me on my toes!)
Two quick comments:
1. I agree 100% with comments already made about the difficulty of reversing or redirecting landscape solutions as opposed to digital solutions. Because of the expense and (sometimes) impossibility of reversing a strategy in the landscape, I think there is a good case to be made for getting the big patterns right in terms of general placement of elements within a design… especially if the placement of those elements involves bulldozers or similar equipment.
Possibly there is a continuum whereby more Up Front design happens on larger scale properties and more Agile design on smaller scale?
2. What is the permaculture equivalent of the Agile concept of Minimum Viable Product?
“A minimum viable product (MVP) is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.”
For instance, is a Jacke Design Concept & Schematic Design a minimum viable product?
Greetings Steve! Right on re comment one, though that said I do look forward to sharing a relatively large-scale example/experiment of an agile approach to permaculture design / development in posts to come (where that said it still involved getting just one big pattern right before starting up the dozer). Re comment two I hadn’t till after reading this comment given this much thought beyond my friend Tom Sparrey’s suggestion that Yeoman’s Water-Access-Structure is like a MPV in a permaculture landscape development context. More on this in my imminent reply to Alex’s reply (And I am fast discovering myself what you mean about Alex keeping one on one’s toes!).
Hi Steve, good to see you here!
Here’s a good definition of MVP that I found:
It has enough value that people are willing to use it or buy it initially
It demonstrates enough future benefit to retain early adopters
It provides a feedback loop to guide future development
I think you can see Dave Jacke’s process as, in some ways, following an MVP process from broad design to detailed design: the design concept is an MVP for the final design.
What I’m wondering, though, is whether the “product” here is the design, or the long-term system in action?
If you conceive of the design concept as leading toward a fully-fledged, “perfect” design on paper, then the paper design is the product.
If you conceive of the eventual impemented system as the product, then I don’t think you have an MVP until you have done the first round of implementation and people are using it and seeing how it feels. But that might just be my agile biases showing 😉
I think this is how I’ve been thinking about it too Alex though I experience it happening at two levels. First before anything happens I’m playing with seeing the objective in a generative/agile process to establish what a (or maybe even the as in the best or most appropriate) MVP is. Here even though it hasn’t happened yet the process seeks to uncover or clarify what an implementable ‘first chunk’ might be where there will be some kind of viable value add as in actual progress on the ground that can be used to then guide (based on people using it and seeing how it feels) the figuring out of what the next MVP might be. Hmmm, first time I have had this thought but it is like the process becomes a sequence of MVPs. As in what is the highest level, most important, and most minimalist (as in taking as few steps as possible) thing we could get on and implement to get the ball rolling here.
Actually in reflecting on what I just wrote I now see a clearer distinction emerging between two ways of understanding how the MVP concept might cross over into permaculture. One is where the MVP is effectively a low-res version of the whole thing, which is akin to a concept design as you are discussing (in Dave Jacke’s sense), whether you’re talking about the paper or the on-ground version. Here, as per Alex’s bias, the ideal would be implementing a first pass of the whole thing. But I struggle with this because you can’t simply implement a concept design, in that details have to enter (as in decisions must be made as to how wide the path is or whatever). Understood in this way, I can’t see how you’d avoid winging a bunch of details, which in many cases if global in scope are going to be difficult to undo / redo based on user feedback. Hence my inclination to use the MVP idea in terms of honing in on an implementable chunk, which initially will be high-level, but will only be one part or aspect of the whole design (concept or detailed). I think this latter sense can definitely still meet the three criteria of the definition you found (I have an example in mind I can share if helpful), though that said if it feels too different from its original context (Alex do you have a good software product development example of MVP and which of these two senses it was truer to?) then I’d be happy to use some other phrase (with a hat tip to MPV for the prompt). Maybe the Right Next Step? Okay people, what’s the RNS here?
ps. One more thought – a huge difference between product development and permaculture is that in product development you are trying to get the input of early adopters into the final product which you intend to replicate and sell en masse. In permaculture design you are trying to help create a single unique ‘product’ for a single adopter (the clients). Here the early adopter is the middle adopter is the late adopter.
You have struck upon the thing which, in Extreme Programming circles, is called “The Simplest Thing That Could Possibly Work” (or as I’m sure you’d put it, TSTTCPW :P). Closely related is the concept of “You Ain’t Gonna Need It” (which is actually abbreviated as YAGNI which at least is pronounceable): you do the simplest thing because there is a strong possibility that if you do something more complex, you’ll over-engineer it and a change in priority/circumstances/etc will mean you didn’t need to do that work in the first place.
In Permaculture, I’ve always thought that the idea of starting from your back door and working outwards is a good example of TSTTCPW: you can establish a small annual veg garden and start obtaining yields in a matter of weeks. And even if you get evicted from your rental property in a year’s time, you’ll at least have been feeding yourself for a while, instead of waiting to have the perfect design for the whole system before starting.
Plus, of course, the things you learn from your Simplest Thing can inform the next iteration.
Will answer your questions about MVP shortly – just wanted to respond to this while I had it at front of mind.
Thanks Alex and no actually I’m getting over my Temporary Infatuation with Half-Serious Acronyms (TIHSA). But great to know about these two and to be striking on what a bunch of programmers already figured out what, like 15 years ago or something ;-). Look forward to your MVP reply…
That phrase “the process becomes a sequence of MVPs” reminds me a lot of the Lean Startup methodology from the startup world (Eric Ries, Steve Blank, etc), where you develop a product with a series of experiments (around product / customer / supplier / marketing / market fit).
Possibly another vein to mine for ideas? 🙂
Oh gosh – so many rich veins to explore! Any keen researchers out there want to volunteer their services to go out and scope one rich vein or another and report back with their findings ;-)???
I have been pondering this for a few days, then just came back to comment and saw your update.
I have to say, I think it’s quite different from where my thinking was heading.
I was going to suggest that you might need to introduce another axis. On the X axis you currently have “degree to which design is done up front vs as-you-go”.
The main other axis I can see is “how much design is done at all”. You could do zero, aka “winging it”. When it comes to designing up front, you could do very little, or you could do years of it. When it comes to agile, you could do less design by failing to iterate, or by failing to “self-regulate and accept feedback” on each iteration (i.e. forging ahead in the wrong direction).
A third axis could be “degree of change in goals and environment”. For instance, in a rapidly changing climate, a very detailed up-front design from 30 years ago might no longer apply. Or for a family who start having kids, their goals could change partway through their permaculture journey.
I think you’d end up with an interesting 3D blob showing where “chaos” falls. I’d love to draw a diagram but I have to go cook an enormous meal for 20+ people so I’ll leave it to your imagination.
* Unchanging environment and goals, extremely detailed and extensive CDDUF: low chaos
* Changing goals and environment, extremely detailed and extensive CDDUF: high chaos
* Changing goals and environment, CDDAYG with good iteration and feedback: low chaos
* Changing goals and environment: CDDAYG without iteration and feedback: high chaos
“Winging it” would tend to have more chaos than not, I think. CDDUF is only low-chaos in a low-change world. CDDAYG thrives in a high-change world, but depends heavily on good process over an extended period to avoid becoming chaotic.
Hey Alex. I had a good ponder of your comment and even played around with a few multiple-axis graphs. What I came to though was that firstly at this stage I’d like to keep things simple/accessible (in the context of where this inquiry is headed the main take-home point I want to emphasise is that there is a continuum of processes from more to less arbitrary which result in systems that are less to more adapted). Second, I have a vague feeling for another kind of axis I’d like to look at introducing later (harking back to my prior inquiry) so don’t want to go cluttering the scene with too many just yet.
That said I’d love to come back to such ideas after sharing an example or two such that these discussions can be cross-referenced to actual real cases. I’d also encourage you to draw that diagram and send it through!
A few other comments is that though I think it is (obviously) important to acknowledge that there is a continuum of how well each of the four (or at least the three right-most in the updated diagram – winging it is just winging it!) approaches are carried out (or what you refer to as “how much design is done at all”), for now I’m happy to assume we’re talking about them when carried out well (plenty of time designing up front, feedback rich in the last two, and so on).
When it comes to “degree of change in goals and environment” this is one reason I dropped the term “chaos” for now – it is slippery and can refer to the process itself, the context in which the process starts, or what becomes of that context over time (either as a result of the process or independently). The picture then becomes more complicated (and the graph more axisy) than I feel is appropriate at this early and provisional stage of inquiry (you might say I’m reluctant to overshoot the MPV here!).
The other thing that happens is we start to enter the territory of both the cynefin framework and adaptive leadership’s distinction between technical, adjustive, and adaptive contexts. Which is great territory well worth exploring, but I feel would confuse or detract from my primary intention here of getting across the fact that there is a simple continuum of design process arbitrariness that permaculturalists would do well to acknowledge, discuss, debate, critique, and most importantly crash test on the ground. Where it matters A LOT in that if permaculture is about enabling/generating adapted and adaptive systems, being aware of one’s process arbitrariness MATTERS BIG TIME.
I like your examples which again come very, very close to what you find in resources on cynefin and adaptive leadership. And though I think it is ultimately all-important that the process itself is adapted to its context, I guess I’m assuming that permaculturists will be interested in a sort of default process or process cluster (which my inkling suggests are in the ballpark of CDUFDDAYG / CDDAYG) suited to highly changeable contexts (which for me includes the environment and user-goals) both because natural systems are always on the move and often in complex non-linear ways and that central to permaculture is having huge relevance in the highly uncertain, unpredictable, chaotic circumstances coming on down the line.
ps. I note that the way you use “chaos” in your comment corresponds closely to how I’d use “adaptedness.”
Wouldn’t it be the awareness of the changing/unchanging environment & goals? A truly clueless designer could be as bad off as a gifted designer in an changing environment.
I’m not so sure that “Winging it” belongs on the left hand end of the chart. If you put it on the right, then the x axis becomes the amount and detail of the process that’s applied — CDDUF being lots, CDUF and CDAYG less so, and WI having none or virtually none. In IT terms, these correspond pretty strongly to Waterfall, various types of agile in the middle and what I call “Code and bugfix” as more-or-less chaos on the end (ie. reactive, knee-jerk, no-idea-when-we’ll be done).
I think of the stages as reactions to the expected/acceptable level of chaos involved in the project. If your requirements are cold and you’re pretty sure there’ll be no surprises, or the costs of errors are large, then CDDUF makes sense – space probes, medical equipment, real time systems, etc.
With higher levels of change, the optimum moves to lower-overhead, trade-off systems like Scrum, agile and XP, where you plan as best you can, but accept a higher rate of error in your design.
And if you have really high levels of change, then even those systems might break down and somewhat-managed chaos is the best that you can do.
A simpler way to put it might be just that the level of process and the level of change are pretty strongly correlated.
A couple of other thoughts:
– Scrum makes a big deal about reflecting and to modifying the process that you’re following (usu. called “retrospectives”), so on any given project you might move left or right as issues or ideas present themselves. In XP, moving left is called a ‘spike solution’, where you quickly plan out and implement a small part of your design in detail to make sure that it’ll work. I’m also reminded of David Holmgren digging soil sample holes for his dam locations.
– If you can make your design process better (faster or more accurate), the optimal process should move more towards CDDUF (and vice versa if something starts throwing a spanner in the works). From what I can see, Dan seems to spend a lot more time on the concept and “feelings” side of his designing now, but with a better result overall.
– “Winging it” will have different outcomes depending on the skill and experience of the designer. A 10 year veteran programmer who appears to be “winging it” could be following a fairly detailed design process, even if it’s one they’ve internalised. This also gives you some shades of grey between WI and CDDYAG, where you might wing it for a while as you work out how to apply some sort of order to a chaotic system.
– Finally, Dan’s idea of being a “Permaculture Design Facilitator” corresponds pretty much 1-to-1 with a Scrummaster role, ie. there to explain and safeguard the process. It’s interesting when the same idea pops up in different fields.
Hey there Anthony!
Great comments though I disagree re the amount and detail of the process applied increasing as you move from CDDAYG and CDUFDDAYG to CDDUF. In my experience because for example CDDAYG involves the wholesale pulling of the implementation process inside the design process there are many thousands more feedback loops and details in the mix making the amount and detail of the process much, much higher than knocking something up on paper or screen in CDDUF mode (even though in CDDUF there is more time/effort spent up front). But I agree that “code and bug fix” sounds like winging it (thanks again for suggesting that term!) and waterfall is the same as CDDUF.
Right on re the correlation between process level and change level. A related distinction in here is that CDDUF works pretty well for mechanical systems but starts falling over when it comes to living systems. Allan Savory makes this distinction using the contrast between complicated and complex.
That’s great to learn how scrum has a process for adapting the process along the way, not sure about your comment “the optimal process should move toward CDDUF” ??, and don’t get me started about the ‘feelings’ side of my designing (all in good time, all in good time) 😉
Totally re it being hard to tell from the outside whether what looks like winging it is actually a master CDDAYG practitioner and your comment about winging “it for a while as you work out how to apply some sort of order to a chaotic system” correlates perfectly with what Dave Snowden says re navigating chaos in this cyefin vid.
Srummaster, love it. Might change the wording on my business card ;-). Dan Palmer, Permaculture Scrummmaster, at your service.
Hmm, maybe detail is the wrong word, but to my mind there seems to be a continuum of “letting go of control”, or something along those lines, as you move from left to right. I can imagine moving back and forth between CDDAYG and Winging It as you work out where you’re going, but I can’t imagine a similar situation for CDDUF and Winging It. It just seems to stick out in odd fashion on the left hand side.
I’ll see if I can re-explain the optimal process part more clearly 🙂 My take is that the process is a balance between the upfront costs of planning, and the onsite costs of development, including any errors. So (eg.) you might avoid the cost of calculating dam catchments in cases where it won’t matter too much, and accept the risk that your dam might not be big enough. But if I write a program to do it automatically from a contour map, there’s no reason for you not to run that calculation all the time. You’re doing less work than before, but your design is more detailed – does that make more sense? There’d be a similar effect for anything that makes your design easier (hand mapping contours vs. using a drone, element analysis vs. patterns).
I definitely agree that it’s hard to plan a design around living systems, including people. There are too many factors in play to consider every possibility, and even if you could your final design would be too complicated to wrap your head around.
Also, I’ve been thinking that you need some better names (or nicknames) for your quadrants. Could I humbly suggest something along the following lines?:
CDDUF -> Engineering
CDUFDDAYG -> Town Planning
CDDAYG -> Exploring
RIGNCD -> Winging It
These are somewhat related to the Pioneers, Settlers and Town Planners in this article, which might be worth a read: http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html
ps. It’s “Scrum Master” – I accidentally a space 🙂
pps. An update after watching the Cynefin video – the left hand edge of CDDUF seems to correspond to their concept of a “simplicity cliff”, ie your detailed plans and procedures lose touch with reality and can’t adapt.
Replying to Dan but it won’t let me reply that deeply… oh well.
Has anyone else mentioned the XP concept of a “design spike”? I have a feeling they might have but can’t find it easily.
you might do something like “winging it” inside a generating process to come up with and test possible next moves, the difference is that you wont actually implement them unless they make it through the filtering/winnowing process integral to a generating process.
A spike is when you say “look, we don’t know the way forward here, so let’s just have a bash at something until it becomes clear whether it works or not.” Maybe you make a rough prototype, or whatever. Maybe you do several and see which one works best.
That could sound/look like “winging it” but if you do it within the context of a generative process, it’s actually more calculated and can help move things forward when they’re otherwise stuck.
Here are a couple of links that have good definitions/explanations of spikes:
You can reply … if you edit another reply URL manually with the right comment id 🙂 I’m not sure what WordPress makes of that behaviour though…
I mentioned the spike solution earlier, but to me it seems that you’re moving left on the scale rather than right, by trying to lay down a small test implementation and adding (supported) detail to your design. It’s not necessarily actual work, but work that you need to do to improve your design, so I’d count it as designing.
Thanks Anthony – so helpful to have your help crash-testing these distinctions before anyone (myself the prime suspect) gets too carried away with them.
Let me share my take on the idea of arranging the continuum around the degree of “letting go of control.” It’s funny because I think the same arrangement makes sense for two opposite senses of “control.” And in both cases winging it stays put on the left hand side ;-).
In the first sense the locus of control is the doer or designer. Here winging it represents the greatest control in the sense that the doer has almost total control of what is being done. It is like they are pointing their magic wand in some almost completely arbitrary direction and ‘poof’ in run some contractors or whatever to plonk the chook house there, or they themselves go and chuck a herb spiral over there.
Then fabrication (CDDUF) represents a little less control, in the sense that actual parameters and constraints of the context (which in a landscape design setting include as ingredients the site, the client, and the designer) have a greater say, but the overall feeling is that the design expert is in control (yet they are still to a large degree imposing their arbitrary whim on the site, just in a more veiled and professionally respectable way).
When we move into the hybrid (CDUFDDAYG) and fully generative (CDDAYG) approaches control in this sense is relinquished as the reality of the unfolding context is given much more say. Indeed in these scenarios, especially the latter, the designer stops ‘imposing’ their expertise from outside and starts facilitating the emergence of what is most appropriate and adapted to the context as a whole.
Now let’s look at it in the opposite sense where the locus of control is not the designer/doer but the context as a whole. Here winging it represents almost no control in that as I mentioned above it is really a highly arbitrary process of imposing stuff willy nilly.
Then fabrication (CDDUF) in a living system context represents an aspiration of high control when in reality due to the lack of real feedback it is a pretence, and can’t help but spin out of control in the sense of going off the rails and flinging itself headlong (if obliviously) into a sea of arbitrary and impositional decisions (even if often the users go along with the pretence and take years to realise that the emperor is naked).
Then as you then move into generating processes (CDUFDDAYG and CDDAYG) the amount of this second sense of control increases, in that these processes enable the reality of the context to exert a more thorough and continuous control or influence over what is being created (as implied by the word unfolding in the above diagram update).
I should note that I don’t really like the word ‘control’ in all this. I prefer talking in terms of process arbitrariness or the degree to which it is about imposing on context vs unfolding from context.
Yet hopefully looking at it through the ‘control’ lens gets across why I’m keen to emphasise that despite seeming close and possibly hard to distinguish at a glance, winging it and generating (CDDAYG) are in fact very different beasts.
You say you can’t imagine moving back and forth between fabricating and winging it, and though I get where you are coming from this is exactly what I see in most back yards and small farms or lifestyle blocks. Where things go is often highly arbitrary (has been winged) where as the actual thing itself (house or whatever) has been designed up front by some expert or another. So the high-level layout and resulting feel is hodgepodge, but the bits themselves are often prematurely over designed. Or sometimes this happens in the opposite fashion in cases where the overall site layout has been expertly designed up front but then the details of house gardens etc are winged. Actually I think there can be a third sense of this interplay where someone tries winging something, it doesn’t work, so they try fabricating, it doesn’t work, so they try winging it, and so on…
On the flip side you say you “can imagine moving back and forth between generating (CDDAYG) and Winging It as you work out where you’re going,” and again I get where you are coming from, but I feel that though you might do something like “winging it” inside a generating process to come up with and test possible next moves, the difference is that you wont actually implement them unless they make it through the filtering/winnowing process integral to a generating process.
Whereas winging it is when there is no real consideration of what comes next. You just do shit blindly and the chances of a coherent adapted system are negligible. I’m realising as I write this that I’m keen to find out from others whether their experience accords with mine – that though on the surface winging it and generating seem like they would inevitably slide in and out of each other, my actual experience is that the nature of an authentic generating process means that winging it just doesn’t get a look in. It is almost like the nature of the process prevents it even being a possibility.
I should note here (this is a note to myself, not to anyone else!) that I think the key to this discussion being meaningful is to get some actual clearly documented examples of design process in the different modes on the table. Otherwise due to the complexity of the ideas and the shifting or alternative meanings of so many of the terms we are using could mean the discussion just sort of wanders on and gets too ungrounded and abstract. And we can’t have that, why we are just getting started here!
I have used a generating process to get a system that has got to where it is by winging it heading back on track toward adaptedness, but in my experience once winging it is entrenched it takes some kind of facilitation entering the scene to find itself being transformed into generating (where the culturally default pushback again winging it is of course fabrication/design up front). Actually in the other direction I have also experienced winging it sort of continuously knocking at the door and trying to sneak in when folk are just getting a feel for being in a generating process. But though folk might slide over the line unconsciously, there is no ambiguity as to the slide once an actual move is made. And early on in a landscape development process at the level of critical whole-site earthworks etc etc winging it is bad (and expensive) news.
Does that all make sense? I hope these ideas don’t come across as too fixed or certain – I’m really just playing with this line of thought, and trying to hone in on what is going to be most helpful here in terms of elucidating these differences. I welcome other perspectives, and in particular I look forward to people’s reactions to this point in the context of the generating example I’ll soon be sharing (after first sharing a hybrid approach).
Your thing about optimal process makes sense though I feel it is still consistent with a generative process?
Thanks for your humble suggestion. In this post as you’ll have noticed I’ve been trying these on for size:
That article looks interesting and that sounds right re Cynefin.
Maybe “attempted | anticipated | aspired | imagined level of control” might more accurately describe what I’m thinking? And yes, reality may have other ideas re. your actual level of control, but the attempt is there. Note that if you can nail down or simplify enough of reality, a CDDUF design can work well and you get very high reliability, accuracy and predictability. I don’t think that’s true for any of the other methods.
Winging It to me is throwing away even the very rough controls or seat-of-the-pants plans that you might’ve developed in a CDDAYG/Exploration phase, in favour of an experiment, wild guess or whim. Self-control is still control (“Man, I really wish I hadn’t put that duck pond there…”).
It makes sense in my head, anyway 🙂
More food for thought:
Systems generating systems:
Thanks again Lilian and the more stuff out there hammering the process-result / generating-generated etc distinction the better!
Trying to catch up on all the posts since January, wow, so much good content (still have to catch up on all the comments). A quick comment of my own for now, too exciting to not take part. 🙂
As excited as you are to discover Alexander’s ideas in the field of computing, so excited was I to also find him in permaculture — he had a very big influence on the field of computer science from the 60s, and had also been a big inspiration for my own comp sci MSc etc., and I was already developing / experimenting with permaculture software when I discovered him. I was introduced to him through Richard P. Gabriel’s book Patterns of Software (available at https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf), that other software developers reading this blog might also enjoy (though it’s older, published in ’96).
Alexander in the foreword:
“What was fascinating to me, indeed quite astonishing, was that in
his essay I found out that a computer scientist, not known to me, and whom I had
never met, seemed to understand more about what I had done and was trying to
do in my own field than my own colleagues who are architects.”
You can read about some more alexander:computing history in RAIN magazine at http://www.rainmagazine.com/archive/2014/gatemaker :
“The Gatemaker project provides an enlightening lens through which to examine the interplay of ideas between Christopher Alexander and computing, over the last half-century. ”
I think though that, as in permaculture and architecture, his ideas have largely been misunderstood in computer science, dehumanised, fragmented. And in many ways these fields have developed / gone down paths that are not quite wholesome. But now many people in different fields seem to be returning to the foundations and early days of those fields, reexamining. And much more inter- and antidisciplinary (see https://joi.ito.com/weblog/2014/10/02/antidisciplinar.html) thought and research is taking place, wonderful and very exciting.
In my experience (which might differ substantially from the theory) Agile and related approaches don’t belong entirely in the CDDAYG camp. As the image below also illustrates, the conceptual product/outcome — the what — is planned (together with the customer) for the final (though provisional) end-product as well as for each step on the way towards it (MVPs, (minimum viable (/lovable etc.) products) with iteration cycles usually 1 to 4 weeks), with only the implementation details — the how — worked out as the developers work towards the desired product/outcome of each step. Change is welcomed, so the initial provisional steps are often changed, but that usually happens at the end of a previous step, not usually at any time (as it then requires joint planning of next steps/MVPs). I.e., there are definite steps with desired and conceptualised/planned products/outcomes. So it seems to me to fit well in CDUFDDAYG. Else halfway between the two. Some thought around MVPs for permaculture implementation would be very interesting.
Good MVP summary image:
Abraham – lovely to hear from you again.
I do like that Alexander quote re Richard Gabriel. Reading the foreword I also love Alexander’s comment (which I reckon applies as much if not more to permaculture) “In my life as an architect, I find that the single thing which inhibits young professionals, new students most severely, is their acceptance of standards that are too low,” and for that matter, and with direct relevance to this inquiry (particularly the latter half):
…the progress my colleagues and I have made since 1985. It is in this time period that the goal of our thirty-year program has been achieved for the first time. We have begun to make buildings which really do have the quality I sought for all those years. It may seem immodest, to presuppose such success, but I have been accurate, painfully accurate in my criticism of my own work, for thirty years, so I must also be accurate about our success. This has come about in large part because, since 1983, our group has worked as architects and general contractors. Combining these two aspects of construction in a single office, we have achieved what was impossible when one accepts the split between design and construction. But it has come about, too, because theoretical discoveries, considerably more potent than the pattern language have supplemented the power of the patterns, and the way they work, and their effectiveness.
In Greg Bryant’s essay on Gatemaker you link to I was at first taken aback to see his comment about Ward and Cunningham’s 1987 paper:
It’s not too extreme to say that the authentic transfer of Alexander’s ideas to the computer industry stalls because of this paper, rather than starting because of it.
But reading on I totally see where he’s coming from, even if it doesn’t really help my strategy of sort of trying to embarrass permaculture into going deeper into understanding Alexander’s work by insinuating the software community is all over it (though it certainly is much more over some aspects, that is for sure). Oh well, back to the drawing board ;-).
Your para starting “I think though…” totally resonates.
I had a bit of a think (along with Steve and Alex) re MVPs in PC this morning you can see here. One thought about the image you share relating back to that comment is that I think that in permaculture systems there is often a third scenario where you can start using implemented bits of the system (such as a driveway) which is different to either stream in the diagram.
Finally your comment about agile approaches being more CDUFDDAYG or at least in between this and CDDAYG resonates with Alex’s earlier comment “In XP, there is a “metaphor” which is a high level articulation of the overall concept, and then software developers tend to work from broad scale to small scale within a session of work.” So yeah I’ll take that on board and modify future iterations of the summary diagram accordingly.
Thanks for all that!
I studied permaculture from Toby Hemenway, and he used EFG as his textbook. It had just gotten published the previous year, I think (2006?). I think we are seeing an emergent focus on design process — something that Mollison himself saw lacking in the current permaculture framework. We see Darren Doherty picking up that mantle (hooray!). EFG was my first introduction to the SOP, and it immediately clicked as waaaay more important than anyone had previously written in framing the structure and process of ecological and pattern fluency for observation and design.
I think the Regrarian synthesis and update of KSOP with Holistic Management hits the spot on the need for sound process framework guiding observation and design, and integration of humans into the whole (and practical things that permaculture so often ignores, like our motivations and available resources, etc). I also think the pattern language has a conceptual design and pedagogical tool remains underdeveloped and underutilized. I wrote up an essay on this topic for a Keyline compilation I’m assembling for my own studies in anticipation of the Regrarians Platform and my own holistic planning process, happy to share any of it.
Anyway, as soon as I learned about the Regrarians Platform, I breathed a sigh of relief and crossed it off my “someone’s gotta do this and it might as well be me” list of projects. It might as well be Darren, with all his various capacities, experience and embodiment of important ethical principles (how many others have openly talked about and integrated their relationship struggles and goals into their ecological design mission?). Hooray!
I’m also working on what I believe is a spiritual successor Toby’s recent focus on “Liberation Permaculture.” Right now the working title is “an ecology of liberatory struggle.” It touches on a few points that David Jacke mentions here about the cultural crisis so many of us feel, and addresses the context and trajectory of the emergence and evolution of the human species.
Thanks for pushing on the innovation and synthesis! To you, David Jacke/Eric Toensmeier, Toby, Darren, Mark Shepard, everyone who continues to push. I also appreciate Geoff Lawton’s reminder that we’ve also only begun to scratch the surface of Permaculture: *A* Designer’s Manual, and it is far from obsolete, but also far from accessible for many of us. Only now do I feel like I have the framework to organize and make sense of it. With these innovations and an improvement in my own thinking and capacities, I feel a newfound appreciation for such classic (and increasingly-relevant) works.
G’Day Ethan and thanks for your comment. Be great to see some of your work around all this stuff and I trust you were pleased to find Darren’s Regrarians Platform approach starring in the very next post. I’ve also no doubt that if you’re working on a piece called “an ecology of liberatory struggle.” you’ve come across Rafter’s excellent work at liberationecology.org
Anyways do get in touch and send some of your stuff through via our contact page if you are at all inclined. I like feeling your excitement about it all, including your spontaneous “hooray!”
ps. Yeah I was touched the first time I read Darren’s holistic context and saw the stipulation that if you wanted to fly him somewhere for more than a week, then you’d need to factor in tickets for his whole family.
Part 7 begins – “Rafter Sass Ferguson has drawn attention to permaculture’s insularity or relative lack of mutually-enriching interaction with complementary developments and disciplines.” I’d re-phrase this as “Rafter Sass Ferguson has drawn attention to HIS PERCEPTION OF permaculture’s insularity or relative lack of mutually-enriching interaction with complementary developments and disciplines.
Perhaps I’m more of a butterfly, but I have lots of mutually-enriching interaction with ‘fellow-travellers’ and ‘allies’. And I see that my peers/colleagues have similar. But for every 10 enriching interactions there are 100s or 1000s more I could have but dont have time/resources to do so. I would argue that p’c is too hard on itself and tho I like R S-Ferguson’s writings, I think he’s too negative. WHY? because without millions of mutually-enriching interactions, permaculture would not have grown from a couple of blokes in a garden to millions of permies doing good stuff.
BUT, Bill Mollison had a vision of an ‘army of field workers’ educated with a PDC and educating others. And that is happening. But do they guide the flow and content of what is discussed by the influential people of the world?
I see too much of p’c as training food gardeners and not enough focus on taking [taking back] the public discourse; to change the trends which left unchecked will accelerate the inevitable crisis. This makes me think of Joel Glanzberg’s call in 2015 to break the mould, http://patternmind.org/an-open-letter-and-plea-to-the-permaculture-community/ and to apply permaculture’s ecological design perspective to current environmental agendas – divestment; Adani coal mine; the inequitable allocation of funding in the recent Federal Budget, etc.
Perhaps p’c is best as a force of edible gardeners? Apolitical but effective? I’m not sure. Whatever, we certainly do need a non-linear and agile approach to design, not a Salim or a Bredim or whatever those acronyms were.
Yes! Let’s “identify the leverage points in OUR design path” – not just for the farm or garden, but for global eco-design as a whole.
Ian – great to hear from you (for other readers info Ian is a recognised permaculture elder who lives in the same town as me) and thanks for chiming in!
I look forward to discussing when I next see you in person, but in the case of permaculture I personally would love to see it being more hard on itself, at least in what I see as the healthy and fun sense of acknowledging blindspots and weak bits and collaborating to make them stronger. I’d see this as a healthy sign of self respect and maturity, where we are all impressed enough with what’s great about it that we can digest and productively assimilate a little critical self-reflection from within.
I have much respect for Joel GLanzberg’s personage and work (along with Bill Read and others from the regenesis group of regenerates). He and I actually have plans to make some trouble next time he’s down in these here parts.
Cheers Ian and love your closing statements:
Whatever, we certainly do need a non-linear and agile approach to design, not a Salim or a Bredim or whatever those acronyms were.
Yes! Let’s “identify the leverage points in OUR design path” – not just for the farm or garden, but for global eco-design as a whole.
More good reading… cheers! Although – I thought at first you were having a bit of a joke with all those acronyms… but it appears not! Can you please just give them approximate descriptive names?
Another point, is that on one hand sometimes upfront design is required (eg client, or community project); but on the other hand (eg my own place), there is a high degree of chaos (especially in the early stages), and Emergent / Actualise design… AYG :-).
Also, when time is very scarce, sometimes a bit of randomness and ‘winging-it’ can generate quite good results – usually depending on the degree to which ‘nature’ can take over and deliver those results. This could be a topic in itself as it depends on the resources used, the time-scale (eg winging it is great for short term planting / design – but long lived trees and infrastructure not so much).
Sort of was a bit of a joke, but I like long jokes and besides people seemed to be taking them seriously until you, Anthony and Alex just went and spoiled my fun by insinuating things were getting out of hand…
Yes I’m inclining toward:
Thanks for your comment re generating and winging it working well together I’d be curious to see what you make of my long reply to Anthony just below? I think your comment about “the degree to which ‘nature’ can take over and deliver those results” is really interesting and yeah right on about being careful where you wing it, if indeed winging it you must ;-).
mind = blown by your definition of organism/organise.
excellent review of different aproaches to PC design
Thank you for sharing this, I’m very much looking forward to reading the next installments.
Thanks Kazel and I’m looking forward to finishing writing them!
Thankyou so much for sharing all this, it’s quite useful!
I often think of how we’re embedded in the old world, trying to design the new one. The problem is that we have to get through the old world to the new, we can’t just plop ourselves down in that new vision. Your rebuilding the ship as it sails is an excellent way to describe this.
I feel like there are many aspects of this old world that will need to be shed, like master plans, top down professional organizations, and even the idea of the designer for hire. But when do we shed what? Some things can definitely go now, while others it’s useful to play with. For example: How can the designer use the gift economy to transform their community, or how can a designer play a role as a regional ecological catalyst.
Hey thanks for commenting Milton – I really appreciate hearing that you found this bit of the report useful – helps me self-justify the time I spent on this little side-series ;-). Great thoughts and questions too – I find my self sitting with some variant of them almost daily. A related aspect to all this is that whilst as you say the new world story must grow out of the old, or we might say that the the new will be birthed from the ashes of the old, it is not always going to be a smooth path from one to the other. If we wait for a clear, well lit path we’ll be waiting a long time. It is important work to be riding on the edge of the old story, bootstrapping our way forward, participating in what feel like healthy attempts to nudge it towards life, beauty, wholeness, sanity, humanity etc (for many permaculture is exactly this), but then sometimes there is a time and place to peek at our inner compass, take a deep breath, and leap ahead into the misty space of the void between stories (hat-tip to Eisenstein here) where we don’t know what awaits, or what will happen, and whether if we don’t like where we end up whether there is any way back. Making Permaculture Stronger as a project is at such a juncture (or maybe it is a continuum?), actually, but more on that in due course!
Thanks Lilian and the experience was just too rich not to share 😉
I’m enjoying your posts. Thanks.
I have just read a book that I think you may find interesting – “Regenerative Development and Design: A Framework for Evolving Sustainability” by the Regenesis Group (https://regenesisgroup.com/). For example I found the concept of ‘vocation of place’ most interesting. Apologies if you know about the book and the regenerative concept already.
In terms of Christopher Alexander’s work I found his book the “Oregon Experiment’ the most interesting to read from a design point of view. I notice you have not referenced it in your posts. I suggest you read it or read it again in light of your present enquiries around design processes. In particular I think the concept of ‘diagnosis’ has a lot to offer.
Besides the book I have not been able to find much more on the Oregon Experiment. Two links I found are:
For an introduction to diagnosis see:
Many thanks for your comment Ronald,
I have a copy of “Regenerative Development and Design” and have huge respect for Bill Reed and Joel Glanzburg from Regenesis, who I’ve been lucky enough to meet and learn from directly. I had a lovely skype with Bill a few days back, and when I explained the juncture I feel making permaculture stronger is arriving at, he replied something like “Dan, that is exactly where Regenesis started!” Along with the work of their colleague Carol Sanford and others I feel that these folk are decades ahead of the game in terms of design process innovation, and I look forward to bringing various threads of their work into the evolving fabric of making permaculture stronger. I don’t suppose you’d be up for summarising their “vocation of place” concept here for myself and other readers?
As for “The Oregon experiment” I appreciate your comment – one reason is that I have never heard anyone mention this book as a design process go-to-book of Alexander’s – usually the spotlight is firmly focused on “the timeless way of building” and “a pattern language”. As you suspect, I have not read the Oregon experiment properly, even though it is sitting on my shelf, having been engrossed in Alexander’s later works, and so your comment has prompted me to make the effort. That said, the material from the link you shared on diagnosis appears to comes straight from the nature of order series (which Alexander spent 30 years writing having found that the pattern language project failed in having the desired affect on architecture). I’ll be curious to track the ideas back to the Oregon experiment.
Best and thanks again,
I appreciate these posts so much Dan and they are sparking spine quivers and ideas of my own.
My “formalised” I.e. post PDC journey into permaculture has taken place at the same time as doing academic studies in climate change adaptation planning. I’ve found permaculture, even with its existing cracks, to be a far richer source of process and ideas for supporting large scale strategic and social shifts than formal adaptation approaches. All these things that you are discussing are so on point! Luckily I now have the mental space to properly dive into this stuff (including the Otto Scharmer theory u and presencing threads).
David’s repeated emphasis on financial system vulnerability is also so important to keep in mind whatever scale we are working on.
Lots to think about!
Thanks Pippa, lovely to hear from you, and I look forward to hearing more when you next come up for air ;-).
Hi Dan, have enjoyed your musing. Coincidently I have found myself immersed in design work again (as well as teaching) here’s a few thoughts I had after reading your posts. I liked your reference to Hakai tossing the coin, and I see that the choice being made around your three or four scenarios (the CD’s), is a little bit similar – maybe no right answer, play the card that sits in front of you. Some clients want a master plan (not too many) some just want inspiration and a bit of knowledge (and everything in between) Some patterns are almost universal, and if your client doesn’t get them, then type one errors abound. Some patterns can be deduced from the joint experience/intuition of client/designer/and some must come out of the interaction of the clients vision and reality of the team implementing some of the major strategies. Thus for me as a designer the focus becomes not on the design process, but the relationship between the ‘designer’/ client/environment which keeps generating the ‘design’/result. I have to admit I have some trouble getting engaged in the analysis of design process method, however i can see that it will support our various paths. Keep going it will improve our abilities. Having watched hundreds of students of ‘graduate’ from design courses, my enduring sense is that most of the ability of good design comes from the life experience of the designer (both materially and emotionally), much of which is either not consciously understood or easily communicated. Yet one of the challenges of ‘teaching’ design courses is how do we work with conscious systems to empower the designer in the person – I don’t have too many answers for that, so i will follow your continued musing with interest to see if I can better my ability to empower others. I too am inspired by Alexanders work, and believe that he has brought consciousness to the understanding he came across out of his own being/observations. There I have started the process.
regards Bob Corker
Bob! Lovely to hear from you – thanks for chiming in and sharing your reflections (Bob and I used to teach design together some years ago – Bob initially put me onto an earlier version of the pyramid shared in this post). Lots of good thoughts but I’m grateful in particular for your statement:
…for me as a designer the focus becomes not on the design process, but the relationship between the ‘designer’/ client/environment which keeps generating the ‘design’/result
Now I find this fascinating because for me, this result-generating relationship, through time, IS the design process. I cannot conceive of anything called design process which is outside of this unfolding relationship, so for me they are one and the same focus. I guess I’d say that the design process (which is really a design-and-creation-process) is the thing that gathers up and co-ordinates the various ingredients (design facilitator, client, space, tools, methods, etc) toward meaningful outcomes.
That said, the main message I get from what you said before that statement is about not being dogmatic or prescriptive about the methods used within the process. The thing needs to be free to breathe and define and adapt itself as things go along. Right on!
I’d be really interested to hear how others feel about this? If you happen to be reading this and find yourself on the cusp of chiming in, then consider this sentence a nudge to help get you across the line ;-).
It`s fascinating to see the evolution of this blog, which I follow pretty much since the whole project started –
The conversation around design process is important, inside & outside PermaCulture movement(s);
The topics exposed here resonate stongly what I was thinking about durning the last few years, reflecting critically on my personal proceses (as an early PC enthusiast but also sometimes critic) as a teacher & designer – I also know of colegues and fellow activists & designers in Latin America, who are engaged in similar discussions in their projects & networks;
Soon I share more on my process & projects
Que bueno oírte Holger and I’m delighted you’re finding resonance with how this project is evolving. It is affirming, actually, in that my intention is for this project not to be about one person’s obscure ramblings but about tapping into shared issues and experiences permaculturalists are facing around the world. I would love to hear more of your thoughts and processes and projects, as well of some of the themes in conversations you are part of. One thought I’m having is if it would ever be of service to have an español section to this site then let me know – maybe we could figure something out.
The real life examples documentation of Melliodora evolving through the implementation process are valuable example. Thanks for sharing this series from your class with David!
Absolute pleasure Bret!
Hi, Dan. I’m excited to see your new podcast; however, I can’t subscribe to it in my favourite podcasting app. Is there some way to turn on RSS feeds in SoundCloud for your channel? I’m not sure how it’s done, but this seems to be the official resource: https://on.soundcloud.com/creator-guide/podcasting
(I’m the guy you asked to review a few articles on agile software and permaculture. Sorry I was so quiet; new baby in the house, I’m sure you understand 😉 )
Hey Paul! I’ll check it out and if can be done, it will be done ;-).
You musta done something, cuz I was able to add it to my podcast app a few days afterwards. Thanks!
Thanks Dan for yet another important piece.
We developed what we’ve called “Our Works Pattern” in the mid 90’s as we were getting busier and needed a stronger workflow. Perhaps interestingly the biggest influence to us developing this pathway was not from within the design professions but from the great book, “The E-Myth” (Gerber, 1993), as it looked at the franchise prototype and applying a systems based approach to various processes and workflows in any business — using the McDonalds restaurant chain as its main example.
Since the development of the Regrarians® brand and Regrarians Platform® we’ve since renamed this as follows:
“Regrarians Works Pattern”
1. Holistic Context Completion & Boundary Reference – Client Completes – 2+ hours – A. Obtain a copy of the 1. Climate chapter of the Regrarians eHandbook, B. Read sections 1.09—1.11 (pp.25-29), C. Complete the 1. Climate checklist (Appendix 3 pp.68-70) D. Create a boundary map in GoogleEarth of the project area and send it to us as a .kmz file.
2. RON – Online – 1-2 hours – Through our interactive (& recordable!) Regrarians ONline service we often have a discussion around key issues/needs ahead of any farm visit. RON is also a stand-alone service through which we deliver training and support
3. Aerial.Topo Map Production – Desktop – 1-3+ hours – Developed & printed ahead of the consultation
4. Regrarians Platform Checklist – Farm – 2-5+ hours – Following through the 10 topics of this renowned platform to cover most elements/issues on any farm
5. Farm WalkNTalk – Farm – 2-5+ hours – Walk/Drive/Ride over the property, generating how-to’s, troubleshooting & suggestions for various themes of development and management
6. Concept Planning – Farm – 2-4+ hours – Sketching of broad concepts for development onto the Aerial.Topo map + designation of broad landscape/management treatment options & processes
7. Digitisation of Concept/Detail Plan – Desktop – 4-15+ hours – GIS/CAD-based concept plans & 3D render development to varying levels of details according to the client expectations & budget
8. Reporting – Desktop – 10-15+ hours – Spreadsheet-based ‘Bills of Quantity’ (BOQ) production that provide estimates to design development
9. RON – Online – 1-2+ hours – Presentation of Concept/Detail plan feedback session ahead of any required revisions
10. Revision – Desktop – 1+ hours – Develop any revisions as required
11. FollowUp – Online/Farm – Ongoing – We’re available to our clients for calls & RON meetings/trainings, P2P & B2B sessions OR follow up survey/supervision work on a pro rata basis
Our current 10 week REX Online Farm Planning Program is based on the ‘Regrarians Works Pattern’ with the intention being that participants are involved in a participatory design process where we facilitate them to develop their own farm plans.
WK1 – Using the Regrarians Platform® Farm Planning Process
Since it was incepted in 2012 the Regrarians Platform (‘RP’) has provided a large number of people with a planning process that is holistic, inclusive and thorough. Its 10 layers are based on the 8 factor ’Keyline® Scale of Permanence’ that the renowned P.A. Yeomans outlined in 1958 and forms the basis to all of Regrarians Ltd. trainings, farm planning consultancies and media outreach. A RP farm plan is not just a design on a map — its a detailed and holistic process that brings together the contexts of an individual, their family, their team and their community with that of the climate and the landscape and region they’re operating in.
WK2 – Holistic Context® for Farm Planning
“…If you’re not designing your life then someone else is…”
– Javan K. Bernakevitch
Striking words from Javan, words that hit the chord of how important it is to establish what Regrarians’ founder, Darren J. Doherty, calls the ‘climate of mind’. The Holistic Context is a potent framework for refining what is truly important in you, your family’s and your teams lives and how that is expressed in the enterprises you work on and the landscapes and communities you work in.
WK3 – Holistic Context Development
The development of a Holistic Context is a critical part of the pathway to creating an achievable farm plan. Within the Regrarians Platform it becomes the benchmark against which all land management and enterprise decisions are made. Develop the understanding about what you really stand for, what makes you and your family (and team) happy, how you can work most productively and how you can build a foundation of landscape, enterprise and community wealth.
WK4 – Farm Map Creation
The advent of the free Google Earth® software has been a boon for land managers the world over — its become a ‘universal translator’ of sorts between all manner of more sophisticated and expensive software and has democratised the power or geography. Learning how to use it effectively and understanding its limits are important steps in building a farm plan. Its also important to set up your Google Earth folders from the start and Regrarians Platform layers are the natural order of these folders.
WK5 – Keyline® Geographic Analysis
“…Water is the principle planning medium. Water comes before roads and fences and everything. If you get the water right, you get the roads right and you plant the trees in the right place, and no-one does that…”
– P.A. Yeomans, 1979
A primary step in the Regrarians approach to farm planning is to use Keyline Geographic Analysis to understanding the principal landscape elements. Once established these elements inform the placement of most of the design features that make up the Development layers of the Regrarians Platform. Using the Keyline Geographic Analysis is at once liberating and powerful as the landscape ‘speaks to you’ (P.A. Yeomans), ‘telling’ you where to put different elements such as water, road, tree, building and fencing systems.
WK6 – Regrarians Platform Checklist Run Through
The Regrarians Platform (RP) process is holistic and therefore thorough. The RP Checklist that goes provides an ‘A-Z’ list of points to consider when formulating a farm plan that will work for you and puts you and your landscape at the centre of the process.
WK7 – Site Analysis
Understanding the ecosystem processes of your landscape and how these interact with the built elements are critical to building an effective farm plan. Using your farm map as a base and applying some simple and yet effective site analysis techniques will help you now and into the future as monitoring landscape function is a key component of holistic land management. We’ll introduce you to the brilliant ‘Bullseye!’ monitoring methodology that our original Holistic Management Certified Educator (HMCE) Kirk Gadzia co-authored. Also to the great work of another experienced HMCE and Regrarians Ltd. associate/mentor in Graeme Hand, who will help you understand landscape function better and is a co-facilitator at this module’s webinar.
WK8 – Regrarians Platform Concept Planning
At this stage of the farm planning process you should have a good idea of what development-based elements should be placed on the farm map. From our perspective its a strong case of “less being more” — whereby planning is focussed on what is needed in the short to medium term though with an eye to future plans and capacity. Typically concept plans will focus on the ‘development layers’ of Water, Access, Forestry, Buildings and Fencing. This might involve planning water storages and a network of pipes, designing some farm roads, orchards and shelter belts, placing farm buildings, the homestead grid of fencing.
WK9 – Priorities for Investigation, Management & Development
Over the course of the last eight weeks you will now have a very sound idea of your Holistic Context and how this is reflected in the development and management of your farm through your concept plan. Now its the time to be ‘Strategic, Pragmatic & Incremental’ — zoom into the planning work you’ve done so far as you look to take the next steps and actualise what you’ve planned. The testing decisions in the ‘Holistic Management Framework’ for decision making will help guide you to what do and what not to do, and when. Does your project need a big ‘D’ development approach or is it a big ‘M’ management approach that’s best for you (or vice versa) ? This is the time to look at deciding which levers you should pull.
WK10 – Recap
Our last week! Do you still have more questions than answers or are you completely ready to dive in? Each of you will be at different stages in where you are at right now. We get that. This week is all about you using the time to open right up about what’s holding you back and where to next and how the Regrarians® Workplace can help you. Regenerative Agriculture is not just about building a new farm, its also about building new communities and continued professional development. The Regrarians® Workplace can help you in a lot of ways so that you are not alone out there and that farm by farm, acre by acre we build the world that we all know is possible when we put our minds and hands and hearts to the task.
Thanks Darren and as you know I have huge respect for your work in design process innovation over the last several decades (hence this post) and gratitude for the important (ongoing) contribution it has made to my own. One thing I didn’t know was the role the E-Myth book had on the early development of what has culminated in the Regrarians Platform! Yeomans meets Gerber ;-). Anyways I appreciate your dropping by and I’ll be hassling you soon about probing your thoughts about this stuff for a podcast.
I wonder if you’ve come across Nikos Salingaros? He’s a close associate with Christopher Alexander. He wrote an interesting series of articles on Christopher Alexander’s design methods in Metropolis magazine that also touch on biophilia and agile http://www.metropolismag.com/author/michaelmehaffynikossalingaros/ and http://www.metropolismag.com/author/nikossalingaros/
He’s also got this weird, often polemical, but very interesting course on youtube here that gets the Nature of Order methods in some detail
Seems germane to what you are trying to do here. Thought I’d chip in
Thanks Aaron and yeah I am in touch with Nikos’ colleague Michael Mehaffy and the books they have collaboratively authored, but look forward to checking out the youtube.
Looking forward to all the dirty nitty gritty stuff Dan. So glad to have seen the place in person, and follow along this inquiry
Good to hear from you Jason and yes that was such a fun visit – hope to catch up again before too long!
What a great record of an exciting process with far reaching positive outcomes.
Thanks mum and dad! Fun to reminisce, hey?
Really nice to see an ‘iterative’ design process going on, I’ve found that I’ve been doing the same in my urban back garden redesign, my only ‘wish list’ point is that I should have designed a bit better around the wind factor (we get hammered). I didn’t bank on the neighbours clearing quite a few trees from a boundary area before my plantings got established. Any learnings from the design process for you?
Lovely hearing from you Vidya. Yes isn’t breaking wind an important function! Main learning I recall was how pleasant this style of designing is, where one can relax out of the space trying to be a design “expert” responsible for coming up with the answers and simply help the design emerge from its context :-).
Main learning I recall was how pleasant this style of designing is, where one can relax out of the space trying to be a design “expert” responsible for coming up with the answers and simply help the design emerge from its context
Sounds like a very gracious way of treating yourself and the whole design process. I myself get so hung up on feeling like I did something wrong if there are any contingencies that pop up. Maybe if we clearly reframe the process (for both ourselves and our clients) as an interative, responsive thing that’s dealing with forces way out of our control, that’s all we need. In a way I feel like it’s all we can do, because it acknowledges the reality that we’re small meat-based creatures that are doing our best in a chaotic universe 🙂
So when’s the book coming out? 😉 You’ve unpacked so much in this post and the previous; your design process is much more clearly articulated than what I learned in my PDC. But it deserves a more stable and structured medium than a blog! So much good stuff; I want to be able to refer back to it!
(I realise that you’re using this blog to flesh out your own understanding — in a generative way, no less! So I guess it truly is a good medium. Still, despite the fact that your ideas are still ‘unfolding’ (see what I did there) they seem awfully ready-to-use already.)
Good to hear from you Paul! Thanks for your encouraging comment. Re the book, maybe check in a few years, see how I’m going with it 😉