In my first post on holistic design, I talked about how designers are sometimes better positioned to approach a project with a holistic mindset (compared to software engineers / developers). This post covers some ideas about how to keep the ‘whole’ in mind even when, as software developers, we have the urge to “divide and conquer”.
Borrow strategies that serve designers and artists well
Find a suitable metaphor for the system – designers do it all the time. Building a mail server? Maybe your metaphor is the post office. There should be one core metaphor, one simple entity or concept that completely captures the essence of what you’re building. If you can’t find a single concept that does the job, that’s your first clue that perhaps you’re building more than one system.
Another tactic: try thinking of the final solution as an organic entity. Anthropomorphise if you have to – but there’s a whole realm of familiar entities that will help you see the system as an organism in it’s own right – you can liken it to anything from a giant metal-crunching cyborg from an alien planet or a cute catterpillar – I don’t care. Anything that gets you into your system’s headspace. Helpful / ideating questions:
- What does it (the system) feed on?
- What feeds on it?
- Is it a predator or prey in a larger system?
- What are it’s bodily functions (what data does it transform) ?
- Does it have limbs? Sensory organs?
And so on. Treating software like an organic entity helps uncover some of it’s internal subsystems. That’s your second slice at holistic understanding.
Okay – by now you’ve started to grasp the essence of what is you’re building. Draw a big fat circle and sketch out the creature that you’re about to manifest with bits and bytes of code. Stare at it and write down what you now understand it to be. It could be something like:
“The new system is essentially a friendly, talking bookshelf that goes onto the internet to find books we’d like, waiting to read them to us.”
The first steps: acorns, not building blocks.
What should the first iteration of development look like for a talking bookshelf? Do we build a ‘shelf’ component for our virtual bookshelf, or the interface to the end-user’s PC speakers, so it can ‘read books’ out loud to us? Should we perhaps start looking at search algorithms for trawling the net for books? Well, in a sense we do all the above, by doing very little of the above.
The ‘acorn’ of this project is any system which has placeholders for the capacities that our talking bookshelf needs. In other words, our first (embryonic) attempt only needs to:
- be able to startup and shutdown (since this organism will live on someone’s PC, these are essential signals from it’s environment that it will need to respond to)
- install / uninstall itself (ditto)
- get content (any content at this point) from a web server and “process” it – processing doesn’t matter – it could just just read a web page and spit it out backwards for all we care.
- playback an audio file – “hello! Goodbye” – who cares? Any sound sample will do.
- store ‘books’ (adding books, removing books). Doesn’t matter what a book is at this point.
The point is, the essence of the application is already there in those few bullet points.
What normally happens at this point is that we gather our developers and dispatch 5 tasks accordingly. Nothing wrong with that. But what do we end up with? Five different components / files / packages. This is not a holistic approach.
Someone – ONE PERSON – needs to publish the acorn version of the project – a simple package with one lonely class – the application class, and it five or so simple methods, and check that in to source control. To make sure that even a complete doofus can be entrusted with this precious task, the acorn needs to be designed intelligently – ideally via a team effort: a whiteboarding, brainstorming session would be great.
And believe it or not, from this humble starting point, a really mighty oak can grow. Even if the compelling paradigm of decomposition takes over at this point, it would be more effective than when used in a divide-and-conquer approach to design and development.