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.
Just want to throw another XP acronym into the pot of alphabet soup: LRM, the ‘Last Responsible Moment’. This is closely related to TSTTCPW and YAGNI. The idea is that you should defer big architectural decisions until a point at which it becomes important to make said decisions for the future good of the project.
Should I put this road here or there? I don’t know; we haven’t established traffic patterns sufficiently yet. Let’s get that annual garden into a spot where we know we want it, so we can have food while we observe traffic patterns. The garden is probably going to influence traffic anyway.
This kinda flies in the face of the Scale of Permanence, I realise. I’m trying to understand how those two ideas ought to mesh together. Maybe we’ve got the Scale of Permanence backwards; maybe we should work from least permanent to most permanent. After all, I can always pave over an annual garden and plant my veggies elsewhere. If I start with the least permanent items, I keep my options open while I continue to gather observations.
What do you guys think? Am I getting too heretical here? 😉
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, this phrase:
[…] and I was already developing / experimenting with permaculture software […]
really piqued my interest. What were you working on? Do you (or anyone else in this discussion) think there’s a gap in the permaculture world that could be solved with software? I’d love to see something like Gatemaker, only with augmented reality. Imagine trying out ideas and being able to walk around them without having to lug around cinder blocks and giant cardboard tubes like Alexander did?
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 find it interesting that, although the software community didn’t entirely ‘get’ what Alexander was after (as evidenced not just in the Gatemaker article but also in the ‘Design Patterns Aren’t’ slideshow that Alex linked to back in March), they (at least Beck, Cunningham, and the rest of the Agile club) seem to be expressing much of his DNA anyway:
iterative, generative development which ‘unfolds’ a whole
letting feedback from the context guide and redirect the design at each iteration
focusing on people
designing as you go
resolving tensions by applying patterns (even if they didn’t form a language)
I’d like to know more about the claims Greg Bryant (the author of the Gatemaker article) is making. I’m not so sure the industry has stagnated in its adoption of Alexander’s ideas as much as he says. Sure, we have a long way to go in order to make our software more human, and there’ve been some outright misunderstandings of what pattern languages were about, but I think Beck and Cunningham’s initial, imperfect forays into Alexander’s world provided the nucleus for a lot of good things.
Not only was there the Agile movement and the wiki, but there’s also User-Centred Design, whose goal seems perfectly aligned with Alexander’s goal of trying to design with humans in mind, trying to find the ‘life-giving quality’. It answers Bryant’s call to design software from the user interface backwards. That’s always been Apple’s approach, and I’d argue that their products often do manage to embody that quality.
(An aside about user-centred design: it’s more concerned about the pragmatics of letting the user get their work done than it is about aesthetics. But I’d argue that it’s still dealing with its own class of beauty: the beauty of the useful. A system which seeks to reduce operational friction for its users creates an invisible sort of beauty. I feel like at times Alexander missed this: in his pursuit of finding that quality, he would sometimes neglect more practical matters. I know that the guy who commissioned Alexander for the Julian Street Inn project was quite dismayed about the cost/budget overruns involved with a certain set of life-giving rafters, the design of which kept homeless people on the street for the good part of a winter, and it didn’t have quite enough bathrooms either. I guess none of us is perfect.)
I also disagree with Bryant’s claim that software folks missed the crux of Alexander’s message. For any piece of software, there are two ‘users’. One is the end-user, the client. The other is the developer herself. We developers spend so much time inside our code that it truly becomes a space we live in. It may be a literary/logical rather than visual medium, but it has just as much capacity to embody hostility or life as architecture does. I’d argue that that’s why certain languages and toolkits become so wildly popular — they do have ‘the quality without a name’, at least for the developers who use them.
(There is, however, always more room to accommodate the primary user — the end user. Software has a long way to go there!)
Why am I ranting about this? I guess I want to tell you, Dan, that your ‘software people understood Alexander a long time ago’ rhetoric still holds water 🙂
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 😉
Revisiting this scintillating discussion after a seven-month hiatus (welcome to baby number three!) One thing I remember not being able to resolve back in February was the tension between element assembly and unfolding.
In the software dev world we’re all about elements because we’re not just assembling the elements; we’re also building them. In that sense it’s more like architecture than permaculture. Complex systems can arise from those elements, and we certainly use an ‘unfolding’ process to improve the elements, but at the very core it’s just elements. That’s why I have to agree with Kent Beck that element assembly really is useful in software design.
Interesting things happen when you start enabling element assembly in this space. Consider the Google Maps mashups of the mid-noughts, where people were combining disparate sources of data onto one map and uncovering very intriguing patterns. This exciting complexity happened because so many services opened up their APIs — interfaces to the raw data — and allowed third parties to connect them in new ways.
So I think unfolding (we call it ‘refactoring’) must happen if you want to arrive at a natural, humane design for your software, but it happens in the context of creating and assembling elements.
How does that apply to design in the real world? Well, the creation/generation bit is inapplicable, for the most part. There’s no way we can build a chicken prototype every time we wanted chickens in our design. There are too many complex systems within the chicken itself, but we get that element, ready to go, for free. And it’s a good thing too, because there’s a lot of good stuff in that highly complex system that is a chicken. It just works. (I’d hate to write unit tests for a chicken: “Assert that, given a pyruvate molecule and an oxygen molecule, a mitochondrion will produce an ATP molecule.” How many tests do I have to write again?!)
Built systems are the exception, I guess — solar panels, buildings, ponds, vehicles, etc. We (or someone) is responsible for making sure all the component systems work properly as we create them.
Anyhow, on to the part that I think is relevant, and here’s the part that I’m still struggling with re: Alexander’s unequivocal assertion that nature works only by unfolding, not by element assembly. At the end of the day, there are elements in our system, and we assemble them. I think nature does this too: the unfolding of a forest and the assembly of its elements into a network are two facets of the same process.
How about this? Unfolding is the process that dictates the proper assembly of elements. It’s the set of rules that decide which new elements will be added in an iteration, which existing ones will survive it, and which will be pruned out. In turn, the emergent properties of that element assembly influences the next iteration of the unfolding.
To me this certainly seems like a useful lens for understanding the creation of complex dynamic systems — including the one you go on to describe at your mum and dad’s property.
Greetings Paul and thanks for your recent spate of comments – lots of great thoughts and concepts. Re the tension between unfolding & element assembly, did you ever see this comment, per chance?
Ah brilliant, I see you’ve wrestled with that idea already. I like what you have to say there. Could I summarise it by saying that differentiation is the governing process, and element assembly is one of the activities that you do whilst differentiating? Whereas in permaculture we often emphasise element assembly to the detriment of all else?
Hey Paul and yeah good summary 😉
I really enjoyed the photos of this design unfolding. As I look at these, what strikes me is how playful the process is. It’s like those life-sketching classes where you work quickly to capture the essence of a pose. Something about the speed prevents you from becoming too self-conscious, keeps you a few steps ahead of your rational mind which wants to squash the fun out of everything with its guidelines and procedures.
When you’re doing BDUF, there’s a tremendous pressure to get everything right because there’s no going back to the drawing board. More rational mind stuff. There’s a time for that — you want to do your engineering due diligence so your retaining wall doesn’t break and send thousands of litres of pond water gushing out over your neighbour’s yard — but it can be quite destructive too. You end up getting quite obsessive over the details, and analysis paralysis can slow you down.
Hi Dan, thanks for a great Sunday workshop!
Since I’m a hands-on kind of guy, this example resonates really well with me. What I still ‘worry’ a lot about though is the dead-end thing that you describe in the footnote. Even though you seem to have worked through every possible way to simulate the implementation, it somehow feels safer to have the whole fabricated design on a piece of paper first…But this might be a cultural bias of mine and has probably nothing to do with how things actually play out.
I have also been a bit troubled about the initial resemblance between ‘Winging it’ and ‘Generating’ and I think I can safely say that there are a few aspiring permaculture designers who feel the same way. This has become super obvious to me when meeting people with really nice and well-designed home gardens who are too afraid to take on the design of another person’s garden because their fabricated designs (the piece of paper) doesn’t look pretty enough. “Yeah I’d love to do another person’s garden, but I have to work on my design skills first” means “I have to work on my drawing/Photoshop skills”. The physical evidence that they are good designers is right in front of them, literally just outside their door. As I discussed with you on the weekend, I think this fear is a serious bottleneck for more space being conquered by permaculture. A generative design process could at least provide a lot of potential designers with just the tool they need to get started. But as you know, I believe it could do much more than that.
Greetings Alexander and so lovely to meet you! – I look forward to meeting again. Yes I think you are right in (very compassionately ;-)) worrying on behalf of a culture that really is most anxious about relaxing into the generative flow too much least something terrible goes wrong. Why take the risk when you can have an expert perfect a masterplan first, make all the mistakes on paper, then simply hand the plan over to the contractors to actualise as drawn ;-).
Also yes that is a fascinating issue that so many aspiring permaculture designers feel inadequate in terms of their drawing or computer rendering skills when in some cases they do indeed have the goods as evidenced by what they have actually created (in some case much more so than those who have been prioritising drawing ideal gardens rather than creating and managing real ones!). But then as you say moving forward then comes down to appreciating the distinction between authentic generating and merely winging it, where at the end of the day it might even be better to go the design on paper first route if winging it is the alternative…
This inspires me to present my portfolio of (a selection of my) designs with focus on the process rather than the result. Thanks Dan!
I’m so glad Linnéa and thanks for dropping by! Would love to see some examples of your processes and whatever it is that happened to come out of them.