Finally, a tight design argument against Agile
Talking to Agile advocates, has been, in my experience almost like talking to Ron Paul supporters: they never let go, can turn anything into an argument for Agile, will play any cheap rhetorical trick available to turn honest concerns into small-minded opposition, and point with fervor to companies you’ve never heard of as shining beacons of the self-apparent rightness of it all. That might just be me, but I do often feel like the crazy person in the room when I say “agile’s not good for everything, and it might short-circuit good design thinking.”
I just started reading “Effective Prototyping for Software Makers” and they’ve got a nice little line:
An overachieving prototype artificially wows an audience by showing inppropriate high fidelity too early in the software creation process. An artificial high fidelity, while it may impress, will often cause many design decisions to be made prematurely — a leading cause for finding yourself designed into a corner.
Coded prototypes have a dangerous effect akin to the picture superiority effect. They imply that many things have been solved which aren’t, that the time-consuming back-end issues are worked out. Worst of all, coded, agile prototypes are an implicit argument that time-to-market is more important than doing things right.
It’s nice to hear software people show some respect for design-time.
Hi,
I know what you mean about the zealotry. That was my initial experience as well. It took me a while to realize that many of the ideas themselves are sound, even if some of the proponents are foaming at the mouth.
You may be interested in the following post on design:
http://damonpoole.blogspot.com/2007/12/desiging-software-is-same-as-predicting.html
I agree that “doing it right” is important, but it isn’t always clear what is needed. So, you can spend lots of time “doing it right” only to have somebody say “that works great, but it isn’t what I wanted at all.”
To be clear, I’m not opposed to agile per se, just the idea that it’s the only/best way to do things.
I’m a huge fan of prototyping, at whatever level of fidelity, and I lament that I don’t see enough of it or enough of it done seriously. Though as you point out its important to match the audience and goals to the “truthfulness” or completeness of the prototype.
But the danger that’s ever present and swallows up teams in no time is the temptation to lock on to the prototype as a solution and begin expending energy solving second-order problems, ie problems created by the prototype’s failures to solve the original problem. They begin to spiral away from solving the original problem with Frankensteinian additions or subtractions to the prototype so that any sort of holistic consistency is completely lost.