Agile (Soon) Considered Harmful?
In the nineties, software development was conceptually simple and straight-forward; you gathered requirements for the system, designed it, built it, tested it and deployed it. This was the era of waterfall, [RUP:Rational Unified Process], [UML:Unified Modelling Language], and lots of up-front design. The more details decided in advance, the less costs from changing later, and thus, the better.
Then, somewhere about the turn of the century, agile development became the preferred way of creating software in the more trendy corners of the development community. Today, mainstream developers have started to follow and software shops all over the place are introducing Scrum, doing test-driven development or using other agile techniques.
In the second edition of his popular book Code Complete, author Steve McConell describes this by saying that while he was writing the first edition, design zealots argued for “big design up-front” (BDUF), and as he was writing the second, software swamis instead argued for “emergent design”, which basically means no initial design at all. As he put it:
In ten years the pendulum has swung from “design everything” to “design nothing”.
Now it seems to me that the pendulum is on its way back.
In an article in IEEE Software, the July/August 2008 issue, Rebecca J. Wirfs-Brock argues in favor of up-front design.
These days, some developers shy away from even suggesting that a project might need up-front design and experimentation. They equate any up-front work with “big design up front” (BDUF) and totally wasted effort. Up-front design needn’t be wasteful if you develop a design rhythm that balances thinking, learning, and doing. You’ll build confidence and sleep better at night.
On a similar note, Justin Etheredge argues that some agile developers might be a little bit naïve.
A lot of developers think that agile development represents doing no design up front. That we will figure out what we want to do and then just jump right into coding it without any concern for what we are going to build. Then we will just come back later, refactor the whole thing, and voila, instant working application. Well, it just doesn’t work that way.
Frans Bouma adds to the theme, possibly suggesting that even laziness might be a part of it.
Yes, Software Engineering is hard, deal with it. Don’t use the excuse that because goals are unknown, because the client changes his mind every day the design therefore has to be done in the code editor. If those are your problems, solve them, deal with them.
My own earlier posts deal with similar issues, such as developers who do TDD without thinking, and that you can't skip design.
To be fair to gurus arguing for the principles of agile development (which to a large degree I myself believe in), these comments apply more to average developer Joe than the gurus themselves. But then, the gurus are probably smart enough to succeed in building their software no matter what process they use. There are however way more average Joes than gurus, so the points above are still very valid.
Given this shift of thinking, where will we head now? Will the pendulum actually swing right back to BDUF? Will we find the sweet spot between emergent design and up-front design? Or will we rush off once again in a new chase for design nirvana? If so, where will we end up this time? I sure hope for the sweet spot option, but given human nature I’m not convinced. What are your thoughts?
I always thought that Agile was about “just enough design, at just the right time”, so to speak, not “no design.” In other words, “emergent design” does not equal “no design”, in my book. It means, just enough design, as soon as you need it, but no sooner. Obviously, knowing what is enough, and knowing when you need it is not a black and white question, and one which things like XP tries to address in an “as simple as possible but no simpler” way.
Anonymous Coward - September 22nd, 2008 at 11:42Thanks for posting dear Mr Coward.
If that is what you think and live by, then you are one of the well informed ones and hopefully successful ones as well. I fear however, that many developers don’t bother to hear much more than “BDUF is bad”. Black and white is easier.
Henrik Jernevad - September 22nd, 2008 at 14:06XP started the zealous push for “emergent design” and Yagni (”You Aren’t Gonna Need It”). As with other practices, it was a “What happens if you peg the needle to one side?” experiment that succeeded remarkably well for what it proposed.
The trouble was that Kent and his crew were too good with the advertising program, and many people thought that because it succeeded sometimes, it was defined to suceed always, and leapt on those phrases without thinking. (”Yay! We don’t have to think any more!”)
There is a middle road — it’s not actually sitting on the emergent design line as many agile zealots think, but it’s typically far closer to the emergent design line than most classically trained programmers and software architects think.
Alistair
Alistair - September 22nd, 2008 at 17:42For more comments, see the scrumdevelopment yahoo group discussion on this post.
Henrik Jernevad - September 25th, 2008 at 22:09