Welcome back to the next instalment in this inquiry into the relation between designing and implementing in permaculture design. We are now up to post 1, 2, 3, 4, 5, 6, 7, 8! I don’t know about you, but for me it’s been a fascinating journey with some unexpected twists and turns.
Speaking of twists and turns, in the last post I zoomed way out and up from permaculture to consider design process discussions in general. There, starting from the wickipedia design entry, I followed my nose to something called the Agile approach.
The Agile Approach
It is an approach to software development that in less than two decades appears to have revolutionised its field. Agile is apparently now used by more software developers than any other approach. There are hundreds upon hundreds of books about it, and it is being rolled out into business management, project management, process management, marketing, naval ship deployment, weddings, family life (for better or worse!) and much else.
In short, it’s a thing.
So what kind of a thing is it?
While this is the best introduction I have found online, I’m delighted to hand this next bit over to someone who can speak both permaculture and agile. Paul d’Aoust, who in a recent comment explained:
I’m a software developer by day (permaculture designer wannabe on the weekends), and a lot of what you said resonates strongly with me. Over the past few decades, the software development world went through a similar set of discoveries — ‘Big Design Up Front’ (BDUF)1 didn’t work well because (a) it assumed too much about the client’s needs, (b) it wasn’t capable of changing its course quickly if client needs changed, and (c) it assumed that the expressed needs of the client truly were the real needs of the client.
Nowadays the darling software development methodology is called ‘Agile development’, expressed most succinctly in the Agile Manifesto http://agilemanifesto.org/ Design and implementation cycles happen regularly (typically somewhere between weekly and monthly), and the goal of each cycle is working software that meets real client needs. (Any given iteration might add anything from a few accounting-related functions that spit out the correct answers, up to a new user interface element that solves a recently discovered pain point for customers.)
The emphasis is on relationships with the client, solving the right problems, small iterations with tight feedback loops, nimble decision-making, and demonstrable results. Sound familiar? Sounds a bit like “integrate rather than segregate”, “articulate goals accurately”, “apply self-regulation and accept feedback”, “creatively use and respond to change”, and “obtain a yield”.
As Paul says, a foundational principle of agile is breaking tradition with up-front design and getting implementation into the design process as early as possible. So Agile is by definition anti-CDDUF. But there are two remaining places it might sit. This further note from Paul helps us locate which:
One mismatch that I see between agile software dev and permaculture is that agile typically just starts working on details and expects a cohesive design to emerge, whereas with permaculture we try to get the big design right to avoid any foundational errors. This is a bit of a caricature, I guess; a good agile developer is always thinking about patterns and overall architecture as they build individual elements. Still, it’s definitely a detail-to-pattern approach.
Despite the apparent lack of up-front design, this works surprisingly well, because (as the Agile axiom goes) you never know what you’re supposed to be building until you start building it. I think another reason it works so well is because of another Agile axiom: refactor (tweak/modify/rearchitect) mercilessly as your project grows.
Clearly Agile belongs if anywhere in the CDDAYG (concept and detailed design emerges as you go) camp. Indeed, taking Paul’s above comment on board it is almost like a new sub-category DCDAYG (let detailed then concept design emerge as you go) might be a better fit. But let’s not get too carried away here with such details (or concepts). I’m putting Agile down as CDDAYG.
So, coming back to the thread of this inquiry as a whole, it is interesting to reflect that:
- Permaculture design process is presented by the permaculture literature in general as all about the big CDDUF (completing a concept and detailed design before implementing)
- Leading permaculture design process practitioners and writers on a closer look are actually are more about CDUFDDAYG (concept design up front then detailed design emerges as you go – e.g., Bill Mollison, Dave Jacke) sometimes also edging into CDDAYG (concept and detailed design emerges as you go – e.g., David Holmgren, Ben Falk), where, as Paul put it, “with permaculture we try to get the big design right to avoid any foundational errors.” It seems to me likely that over time that permaculture’s centre of gravity will drift in this direction (though a lot of work is still required to clarify the details).
- Christopher Alexander and the wildly popular, influential, and fast-growing Agile approach are over in CDDAYG.
A Key Difference Between Developing Software and Developing a Landscape
I want to emphasise a key difference between software development and landscape development: the relative reversibility of implemented decisions.
My friend Tom Sparrey has put it this way:
Agile works so well in software because you’re dealing with digital elements, easily rolled back or altered if there’s a functionality problem or bug, whereas in the physical world if you make a big change (i.e. a $10,000 new driveway), you want to make sure you’ve considered it thoroughly (plenty of immersing/emerging) before making a move.
I will come back to this matter in subsequent posts. In particular, I will be exploring this question: does this relative irreversibility in changing the physical (as opposed to a virtual) landscape require a whole-site concept design up front? Or is there some way of safely entering the realms of CDDAYG short of this? Thankfully this is an empirical question and so I’ll be testing it empirically, in the context of a full-scale permaculture property design and development project.3
The Plot Thickens
The day I started writing this post maybe a month or so ago, I was emailed by Takeshi Kakeda4 who is not only a Japanese student of both permaculture and the work of Christopher Alexander5 but a software development consultant.
Naturally, in my reply, I mentioned that I was at that moment researching the Agile movement in software design. He replied explaining that a well known instance of agile called extreme programming (or XP)6 was hugely influenced and informed by the work of none other than Christopher Alexander! Takeshi went on to say that:
Software people paid attention to Alexander’s work, and have been interchanging since the 20th century.7
A few weeks later Paul commented that:
The early proponents of Agile were also big fans of Alexander8
Then Lilian Ricaud added this comment:
Like Paul d’Aoust I emphasize there is a strong link between what you described and the methodologies used by agile practitioners (Ward Cunningham was strongly influenced by Christopher Alexander) and design thinking methodologies.
Reminding me of his interesting essay Permaculture patterning: a design framework for systemic transformation (2015) in which he wrote:
Indeed, in the last few years new schools of thought have emerged in the design field. Pioneered by developers seeking to improve their ability to deal with complex software building projects, agile methodologies embed in their process several principles common to pattern languages and per- maculture approach: (iterative steps, structure- preserving unfolding, adaptive instead of predic- tive approach, use of feedback…). Interestingly Ward Cunningham, inventor of the wiki and one of the main actors of the extreme program- ming methodology and the Agile Manifesto was directly influenced by Alexander (p. 202)
Following up these comments, I found this on Christopher Alexander’s wikipedia page:
In the field of software, Alexander is regarded as the father of the pattern language movement. The first wiki – the technology behind Wikipedia – led directly from Alexander’s work, according to its creator, Ward Cunningham. Alexander’s work has also influenced the development of agile software development and Scrum (From the Wikipedia entry on Christopher Alexander)
Well this was a surprise! No wonder Agile is over with Alexander in our diagram – Alexander was a formative influence in its very creation!
Digging Deeper into the Alexander-Agile Connection
This discovery left me curious to track down the point where Alexander’s thinking started wielding an influence on software development. I believe I found it. At a significant gathering of computer programmers in 1987, Kent Beck (father of the Agile approach called XP or eXtreme Programming) & Ward Cunningham (inventor of the wiki9) presented a technical note in which they wrote:
We propose a radical shift in the burden of design and implementation, using concepts adapted from the work of Christopher Alexander, an architect and founder of the Center for Environmental Structures. Alexander proposes homes and offices be designed and built by their eventual occupants. These people, he reasons, know best their requirements for a particular structure. We agree, and make the same argument for computer programs. Computer users should write their own programs. The idea sounds foolish when one considers the size and complexity of both buildings and programs, and the years of training for the design professions. Yet Alexander offers a convincing scenario. It revolves around a concept called a “pattern language.”
A pattern language guides a designer by providing workable solutions to all of the problems known to arise in the course of design. It is a sequence of bits of knowledge written in a style and arranged in an order which leads a designer to ask (and answer) the right questions at the right time. Alexander encodes these bits of knowledge in written patterns, each sharing the same structure. Each has a statement of a problem, a summary of circumstances creating the problem and, most important, a solution that works in those circumstances. A pattern language collects the patterns for a complete structure, a residential building for example, or an interactive computer program. Within a pattern language, patterns connect to other patterns where decisions made in one influence the others. A written pattern includes these connections as prologue and epilogue. Alexander has shown that nontrivial languages can be organized without cycles in their influence and that this allows the design process to proceed without any need for reversing prior decisions
Hmm, this tempts me to dive a little deeper than I intended to go inside this particular inquiry. But oh well, what the heck. Let’s go there. Yo see I have been aware for a while that at some point someone needs to properly explore the relation between Alexander’s work on pattern languages (which permaculturalists are very fond of) and his work on the design-implementation relationship inside a nature-mimicking organic unfolding process (which permaculturalists seem to have missed or at least not mentioned if they are aware of it). For, as Alexander stressed more and more throughout his career, the two are intertwined to the point of being inseparable if the application of either is to be done justice.
In the above snippet, which I believe marked the start of Alexander’s enormous (if completely unintentional) influence on the software development world, Kent and Ward convey at least two significant aspects of Alexander’s pattern language concept when applied as he intended:
- As soon as you start breaking down the boundary between design and implementation you start breaking down the boundary between designer and user. The user becomes a design participant rather than a design recipient.
- You can do this incrementally and iteratively in a way where you can implement bit-by-bit (where implementation is inside and integral to design rather than happening afterwards) and yet not have to then go back and reverse a prior decision. In their words, “nontrivial languages can be organized without cycles in their influence and that this allows the design process to proceed without any need for reversing prior decisions.” Alexander himself came to call these “backtrack-free sequences,” which we will return to in a very practical way later in this inquiry.
Now Kent and Ward don’t in the above statement clarify fully what they mean by “a radical shift in the burden of design and implementation.” But given that a cornerstone of the subsequent development of the Agile approach (Which Kent and Ward were key players in) is moving away from CDDUF (concept & then a detailed design up front) toward CDDAYG (concept and detailed design emerges as you go) with a crazy-tight continuous iteration between designing and implementing (and hence designer and user or client) I think it’s clear they were tuned into the significance of this stuff from the start. They got pattern languages. But they also got the idea that the patterns therein work their best only inside a generating as opposed to a fabricating process.
Wow. Epic. When I casually googled “design process” at the beginning of the last post, I had absolutely no idea what I was getting myself into.
We’ve seen that Alexander’s critique of the conventional separation and chronological sequencing of design and implementation has triggered massive, global-scale transformation in the software design community (via the Agile movement). This transformation is being embraced and channelled in almost every direction imaginable.
Despite permaculture’s soft spot for Alexander’s pattern language concept, Alexander’s more fundamental ideas about the character of nature-mimicking design in terms of what it means for the relation of design and implementation do not yet seem to have been fully appreciated (at least to the point you find this stuff mentioned in the permaculture literature).
In spite of this, I have detected a movement inside part of what we might call the cutting edge of permaculture design away from CDDUF (completing a concept and detailed design up front before implementing) and toward CDUFDDAYG (concept design up front then detailed design emerges as you go).10 In David Holmgren and Ben Falk’s case we’ve even seen an inclination towards going a step or two further into the land of CDDAYG (concept and detailed design emerges as you go) – the land Alexander and the Agile folk appear to reside.
Now I don’t know what you make of all this, but I personally would venture the following conclusion. In at least one important respect, many modern software designers are using design processes that are more sophisticated, more throughly researched and crash tested, more adaptive, and in some ways even more nature mimicking than the processes used (or at least publicly taught and communicated) by permaculture designers, who ostensively are all about mimicking nature!11
What is up with that!?!
One might even go so far as to claim that in its insularity from design science in general, and software development process in particular, permaculture as a whole has quite simply been left behind when it comes to the best and most effective design process understandings.
Yes, at the end of the day this stuff has been used in software design to more efficiently generate, well, software. I am not saying the stuff it creates there is necessarily of that much interest to permaculture.12 I am saying that the way in which it creates that stuff maybe should be, given that it is some important ways several steps ahead of the game.
As a permaculturalist, I have to admit I found this all a little embarrassing at first. But in a good way! In a motivating way! In a “sleeves up people – we got some catching up to” do kind of way.
The findings of this post have clear implications for our inquiry. In a twist I never would have expected, as we strive toward a fresh and more internally consistent conceptualisation of permaculture design process, we’ve realised that as counterintuitive as it may seem for people interested in real plants and animals and water and soil and sunlight, the agile movement in contemporary software programming may have a lot to teach us about getting better at what we do in our own domain.
In the next post, I’ll start introducing some field-experiments13 where I’ve been putting some of these ideas to the test on the ground.
- This is where I got the idea for the acronyms in the last post – yep, you can blame Paul
- Note adding the terms of the last post, we we might say fabricating is akin to the ‘rational model’ and generating the ‘action-centric model’.
- Thanks to a trusting group of clients including Tom and his new driveway!
- Takeshi was asking permission to translate and republish some Making Permaculture Stronger posts in Japanese.
- working under Hiroshi Nakano, who designed the famous Eishin High School project with Christopher Alexander
- Paul recently mentioned XP in this comment
- For the record, he went on to say “But I don’t know whether permaculture people did. I hope that permaculture people, pattern people and software people share ideas and make the world better”
- For the record, he went on to say “there are many pattern libraries available for programmers who don’t want to re-solve solved problems. They tend to be articulated in similar ways to Alexander’s patterns: state the problem, give a label to the pattern that solves the problem, then describe (in a general way that’s not tied to any programming language or architectural methodology) the ‘recipe’ of the pattern.”
- wikipedia ironically being the very place I’m finding out most of this stuff!
- I won’t go into the fact that Dave Jacke and Ben Falk were profoundly influenced by Alexander’s writings, David Homgren was heavily influenced by Alexander’s pattern language concept, and Mollison was familiar with and had much respect for Alexander’s work. I mean just who the heck does this guy think he is having such a massive impact on so many people and professions!
- Not to mention working in an area arguably more relevant to riding out the interesting times ahead than (mostly corporate) software development!
- Though nor am I discounting the possibility for contributions to permaculture from the software world
- As in actual fields, full of grass and soil and stuff.