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

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

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

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

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

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

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

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

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

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

The Rational Model posits that, amongst other things…

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

…where typical stages include:

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

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

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

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

Criticism of the Rational Model

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

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

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

The Action-Centric Model

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

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

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

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

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

Recap

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

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

Where to From Here?

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

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

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

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

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

References

Ralph, Paul. “Comparing Two Software Design Process Theories.” In International Conference on Design Science Research in Information Systems and Technology, 139–53. St. Gallen, Switzerland: Springer, 2010. https://pdfs.semanticscholar.org/12e4/5521bf4ca5edf3c4acdaf6076be7cdbb307a.pdf.
Rohr, Jascha, and Sonja Hörster. “THE FIELD-PROCESS-MODEL,” date unknown. http://www.partizipativ-gestalten.de/the-field-process-model/.

Endnotes

  1. Amongst a raft (as opposed to a canoe) of high-calibre contributions to permaculture
  2. See especially this paper
  3. which aside from dabbling in a little Christopher Alexander and chatting to an acorn has not left permaculture-world
  4. or so I thought!
  5. Check out this rare example of someone making exact same point in a permaculture context:”But when it came to teaching how to actually do the design itself, even Bill Mollison’s Designers Manual – a weighty compendium on permaculture – went silent. Some permaculture designers must have realized this weakness of the original work and offered classic design process models to permaculture design. The two widely used process models came from engineering. They were named the SADIM and the BREDIM design processes. The abbreviations stand for Survey, Analysis, Design, Implementation and Maintenance and for Boundaries and Resources, Evaluation, Design, Implementation and Maintenance respectivelyBoth models suggest a straightforward design process with easily understandable steps to follow. However, our observation has been that all the students who had been taught these models never actually followed them. Even when we tried to force them by asking them to document their own design process, they never took the steps suggested by these models. Rather they arrived at their design in some other mysterious way and retrospectively tried to describe what they had been doing using the SADIM or BREDIM models. The result often was both frustration and boredom.This puzzled us and even though  we have taught design along these processes, our own designs didn‘t follow them either. So what was happening? Were we all bad designers who couldn‘t follow a simple process or was the theory behind these models wrong after all?” – from Rohr & Hörster (date unknown)
  6. Also see this page on the related concept of a minimum viable product – thanks to Tom Sparrey for this link

4 Comments

  1. 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! 🙂

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

  2. Hey Dan..

    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…

    Mark

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

Leave a Comment

Your email address will not be published. Required fields are marked *