The acorn seed: a tiny thing, with the enormous potential to become a mighty oak tree. The realisation of this potential is often used as a metaphor for evolutionary design – but this leads to several unhelpful perceptions.
The acorn doesn’t ‘evolve’, in the Darwnian sense, into an oak tree… far better to realise that the acorn is an oak tree.
The phrase ‘evolutionary design’ is bandied about a lot, and it wherever it is used – upon closer inspection – it’s almost certainly the process of design and development that is evolving (usually haphazardly), not the thing that is being designed or developed. As a result, instead of building an ‘acorn’ that will blossom into an ‘oak tree’, we just end up with lots of discarded ‘nuts’ everywhere, feeling our way through the dark toward the one iteration of development that looks like it’ll take root.
Understanding the parts vs understanding the whole.
There are 2 ways to get a project off the ground: to tackle each piece of it separately, and in turn, until everything is complete – or to build a tiny piece of every subsystem right from the start. Thankfully, the ‘divide-and-conquer approach’ and the ‘holistic’ approach aren’t mutually exclusive. In fact, the two approaches should interact. Unfortunately, dividing and conquering suits the categorizing human mind much better than trying to understand the ‘essence of the whole’.
A more holistic approach – i.e. perceiving that the acorn *is* an oak tree – requires far more analytic rigour up front. To build a system in this way demands that you understand what the end-product will be, and be prepared to deal with its complexity right up front. Since it’s human nature to want to cross bridges only when they’re finally encountered, most holistic design is doomed from the outset.
Developers could learn from design and branding teams
Because of the nature of computing, software projects in particular are very prone to a decomposition-only paradigm. People in arts and communications fields are much better trained at grasping what the ‘essence’ of something is. They are able to ask “What is this thing?” (Not, “What does it do?”). If a bunch of designers were given an ‘oak tree’ as their design objective, and then were locked in a room, This is how the conversation round the table would go:
“Ok, so I’m thinking wood. We wanna evoke the texture – tree rings, not wood grain, thanks. Lots of brown. What else? Drawing up water from the ground, turning sunlight into energy – transformative processes. ‘Transform’ – we’ll need to play with that word. We want transformation but we’ve also got ‘rooted in the earth’. What else? Shelter and shade. Hang on – what do Oaks symbolise? I guess strength… We’ll need a bold serif. And some green hues – signifying nature…”
Lock a team of developers into a room and give them the same ‘oak tree’ as their development objective, and you’ll get a conversation something like:
“Hmm.. why don’t we start from a Tree class and subclass the Oak from it? You know the client’s gonna come back and ask for Elm trees and Willows, so we might as well start with a basic tree class. Jim and I can work on the branches. Sue – d’you think we could reuse the trunk from the Forest project we did a while back? You guys can work on the leaves and roots. We’ll outsource the photochemistry algorithms…”
Based on these two made-up conversations, it would appear as if the design team is better at starting with the end in mind, with unifying (tree-relevant) concepts, and staying that course.
The development team appears to start off that way too, but there’s rapid divergence from the holistic viewpoint until they’re dealing with parts of the solution – a reductionist approach to be countered with an integrative phase near the end of the project life cycle.
Obviously, someone has to work on ‘branches’ and ‘leaves’ at some point – that’s not the issue here. The issue is that it’s easy to forget that the branches and leaves are part of a tree, and that it’s worth spending time figuring out what exactly a branch starts out as.
In the next part (part 2) of this post, I’d like to posit some ideas about how a development team can re-orient their relationship with solution domain – in a way that allows them to start with a true microcosm of the final product. In so doing, the development effort benefits from Nature’s own laws about how things grow.