Tom Breur
30 July 2013
Agile practitioners love to demonstrate the fallacy of Big Design Up Front (BDUF). And –of course– the illusion that you can predict and plan a big project up-front has proven time and time again to be both an illusion and a waste of time.
I used to have a boss who loved to moan: “Never time to do it right, always time to do it again!”
Large software projects cannot be architected up-front, a significant part of the architecture gets redesigned as the rubber meets the (coding) road. This design-as-you-build is certainly not unique to Agile projects: Waterfall projects use it just the same. Except that they learn this ‘the hard way’…
So if we accept for a moment that design emerges as you build how does this bode with developers working in parallel on –supposedly– independent tasks? Every design change potentially ‘touches’ on existing code (unless it’s perfectly compartmentalized), and may well interfere with parts of the system someone else is currently working on (but hasn’t released, yet), or had in mind for the near future.
This is where thoughtful and repeated planning (the verb!) holds its own. Yes, it costs more time, and yes, this is waste. Waste that you should make up for by improving the flow of work. Planning helps to ensure design integrity, share coding standards, foster collaboration, and also enables independence of stories by explicitly defining the anticipated interfaces.
If you think careful planning takes too long, try rushing it ☺ (and doing it again)
No comments:
Post a Comment