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
From what I can gather, the Agile approach is the pointy end of the action-centric stick we discussed in the previous post.
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”.
See also this further comment from Paul, this note from Ethan Roland of Appleseed Permaculture and additional mentions of Agile-Permaculture affinities here and here and here and here.
So where does this land the agile approach in terms of the categories I developed in the post before last? Here they are again:2
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.
Summary
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.
Endnotes
- 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.
Hi Dan,
After 4 years, I finally noticed the discussion 🙂
In the end, what conclusions or learnings did you come to about the relationship between agile and permaculture design?
I wish I could have participated in the discussion in real time.
Your curiosity and inquisitiveness is so great.
Best regards.
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 😉
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:
http://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-.jpg
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):
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:
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
finding ‘centres’
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 🙂
Abraham, this phrase:
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?
Paul, hi.
Sorry for the slow reply, only saw your comment now when I opened an old browser tab to come see what has happened on this site in the 6 months since last I was here.
Re “For any piece of software, there are two ‘users’. One is the end-user, the client. The other is the developer herself…” Yes!, the motivation for my MSc was that “the QWAN should similarly be pursued for and by programmers, the inhabitants of code” and to “make the code [development process] habitable for them in the Christopher Alexander sense.” Thesis is available online at http://scholar.sun.ac.za/handle/10019.1/96853 if you were interested.
I definitely think there’s a gap in permaculture where software can assist. PCs for PC, :p .Greatest results will be when they work together in a synergistic way that uses their respective strengths. Computers are super fast, always available and can store huge amounts of data, so can be used to simulate, to solve, to visualise, to ‘teach’, to give insight by allowing for exploration of dynamic systems (system behaviour over controllable time), to provide context-sensitive information, etc.
I’ve been experimenting with and working on all sorts of things over the years, when I have time. Some ideas discarded, loads of ideas lie ahead, some busy with (e.g. automated layouts based on user-specified constraints and properties of user-chosen elements using machine learning), and some parts done (e.g. modelling of water flow and time- and location-accurate solar) that I’m combining, over time, into one large program: A game-like simulation system for permaculture, for both designing (human as designer in control, computer coming alongside with visuals and data and computation to quickly solve constraints and so collaboratively explore possibility spaces) and for learning (play-based learning by solving scenario-driven puzzles, not deterministically but as multifaceted goals, say like the old game The Incredible Machine combined with a Sim game). My job is in AR (and 3D, simulation, etc.), so I do have AR in mind as one (but secondary) way of interacting.
The professional permaculture world and professional software development world are generally quite some distance from each other. I get very excited about their moving closer together (as of course they already are, computation and everything), and the effect of every single person becoming a designer of their own regenerative and sustainable environments.
Hi Dan,
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?
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?
Your thoughts??
ps. One more thought – a huge difference between product development and permaculture is that in product development you are trying to get the input of early adopters into the final product which you intend to replicate and sell en masse. In permaculture design you are trying to help create a single unique ‘product’ for a single adopter (the clients). Here the early adopter is the middle adopter is the late adopter.
You have struck upon the thing which, in Extreme Programming circles, is called “The Simplest Thing That Could Possibly Work” (or as I’m sure you’d put it, TSTTCPW :P). Closely related is the concept of “You Ain’t Gonna Need It” (which is actually abbreviated as YAGNI which at least is pronounceable): you do the simplest thing because there is a strong possibility that if you do something more complex, you’ll over-engineer it and a change in priority/circumstances/etc will mean you didn’t need to do that work in the first place.
In Permaculture, I’ve always thought that the idea of starting from your back door and working outwards is a good example of TSTTCPW: you can establish a small annual veg garden and start obtaining yields in a matter of weeks. And even if you get evicted from your rental property in a year’s time, you’ll at least have been feeding yourself for a while, instead of waiting to have the perfect design for the whole system before starting.
Plus, of course, the things you learn from your Simplest Thing can inform the next iteration.
Will answer your questions about MVP shortly – just wanted to respond to this while I had it at front of mind.
Thanks Alex and no actually I’m getting over my Temporary Infatuation with Half-Serious Acronyms (TIHSA). But great to know about these two and to be striking on what a bunch of programmers already figured out what, like 15 years ago or something ;-). Look forward to your MVP reply…
Hi Dan,
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? 🙂
Anthony
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 ;-)???
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? 😉
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!).
“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:
https://github.com/lilianricaud/patterns/blob/master/Extreme_Manufacturing_Patterns/XM_patterns.md
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!
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.
Hi Dan,
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.
Alex
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).