One of the big debates over the last 5 or 6 years – maybe more – is how much ‘upfront’ analysis and design should be done on a project.

From what I can ascertain by talking and listening to people, or even just by general observation, developers hate the notion of upfront analysis and design.  I’ve never been quite sure why. In many cases I think it must be down to developers having had bad experiences with traditional ‘waterfall’ cultures. In recent times a new generation of developers have come through, who are influenced by hearsay stories from others about bad experiences with traditional ‘waterfall’ cultures. In a way it’s understandable; What really scares a developer is the prospect of being given a telephone directory-size requirements document and told to get on with it. Typically, the people that wrote such documents would then hand them over and then pretty much disappear off the scene, only to re-emerge later once the software had been built (or more likely once the project had gone wrong, completely changed or both, and they were reluctantly dragged back on to sort it out).

Upfront analysis and design is still vitally important.  It is just a matter of being perceptive about what is needed.

Back in days of old, when I used to work on waterfall projects and did ‘traditional’ upfront design, I never once produced telephone directory-style documents, though I did heavily adapt the deliverables to the project in question. But even then, one of the criticisms constantly levied was that by the time the system had been built, everything had ‘moved on’ and the original design didn’t represent what was eventually delivered. People implied – often in a rather sneering tone – that because things had moved on, the initial design was a  pointless waste of time and money and completely null and void. We could have in some way done without it.

To me, though, this is missing the point. It goes against how I would interpret ‘design’ and the purpose of ‘design’.

Consider you are having your kitchen rebuilt and reinstalled.  The kitchen company will spend time designing the finished product and providing drawings, illustrations and diagrams for you to approve.  I would hazard a guess that you would not proceed without these (a fact that is interesting in itself and says alot about the notion of iterative development).  Yet the purpose of the drawings and diagrams isn’t to prescribe every minute detail of the finished product or to ‘lock you in’ to something.  Any kitchen company worth its salt will be prepared for certain design alterations to be made as the work goes along: The customer can’t possibly visualise everything in advance and it’s only once you get underway and start seeing things for real you can start making proper decisions.

On the other hand, not everything can be changed.   In my kitchen, it turns out there are only one or two places where the combi-boiler can go. This has huge implications for the overall design.  Furthermore, the appliances can also only go in certain places.  The gas meter has to be in one specific place. Once these constraints are known, there is little point in me coming up with endless design changes requesting things that can’t be done (or at least unless money is no object).  One we recognise this, the kitchen company’s drawings, illustrations and diagrams taken on a new meaning. Far from being a rigid statement of ‘what I will get at the end’ they are actually part of an education exercise which gives me a practical outline of what is being aimed at, with guidance on what changes I can and can’t make.  Knowing what you can’t do – negative as it may sound – is often the most important aspect of analysis.

In my view, people confuse the word ‘design’ with ‘instructions’.   Many developers assume ‘design documents’ will be some form of detailed instruction telling them to the n-th degree what to build and how.  A kind of ‘painting by numbers’ exercise.  I’ve no doubt there are some some sectors and industries where this is necessary, but for many IT applications, the design – like the kitchen example, is more about education and guidance, and assisting the team. Nothing sinister, bureaucratic or waterfall about it at all.