Take pause and appreciate with me a moment of enormous visual power, created “accidentally-by-design” in the convergence of flickr and lunch-in-a-box.
Further proof that a simple framework can yield astonishing visual results, and of course that the world wouldn’t start wobbling on its axis if we spent less time on kickin’ web graphics and more time designing our plates…
The always-sensible Jeremy Miller drew my attention to this discussion today. He highlights this point, from Ron Jeffries:
I think “requirements” always means approximately “what we think, right now, that we need”.
To borrow a phrase from Nick, Gak!
This kind of talk actually changes the physical constants of the universe, significantly decreasing the inertial force of the agile development agenda adoption rate. You can just hear the seismic rumblings of indignation from space shuttle OS architects and the other remaining core demographics for the Big Design Upfront community.
If you catch it in just the right light though, on just the right time of day, you can see Ron’s point: No requirements are final. Next year, or ten years from now, we’re going to need a better boat. No doubt.
Under sub-optimal reading circumstances, on the other hand, this completely misses the point. Especially in a world of progressively more and more application infrastructure that seems to support an iterative approach. So, as we take an iterative design model more for granted every day (I was talking to someone who surprised me by referring to it as “canonical wisdom” last week), it’s worth repeating the old chestnut: Agile does not mean no design. Just because no requirements are divine, we still need to think out our applications all the way through before we start making them.
Luckily, it seems like the idea that you can just iterate your way through a series of bad designs is on its way out, but now more than ever, the web application universe could save itself some trouble by just co-opting a lesson the desktop folks had to learn the hard way. The “iterative” approach isn’t used to fix broken or bad features, it’s used to add features.
So, whether you want to list out specific database tables, class diagrams, or pseudocode for algorithms in your spec is, if not exactly immaterial, certainly is not the point. That kind of thing is best decided on a project basis, and is pretty dependent on your org chart and the size and project-load of the senior members of your team (aka. do the “architects” keep working on the project once its designed, or do they have to go off and specify something else?). There’s No Silver Bullet.
Seems pretty sensible right? Well, unfortunately, sometimes work isn’t.
One of the arguments you hear someone make from time to time is that agile design eliminates the need for the “throw-away first system.” The throw-away first system is a venerable tradition of admitting our own impotence in the face of our technology and a classic strategy that begins with one of our greatest software writers and ends with the (::Williamsburg-style “how-apropos”-grimace::) waterfall development agenda. It comes from a time when the problems were hard, when Google couldn’t provide you with example code, and when a movie cost a nickel. Ladies and gentlemen, Mr. Fred Brooks:
Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.
This strategy addresses a problem that was significantly more prevalent in Fred’s day: What do you do when there’s no map? And I don’t mean there’s no map for the implementation details, I mean there’s no map in the sense that you’re dealing with a totally new problem. Back in the 1960’s this was often a technology problem - less and less is this the case.
So, given that we can now instantaneously call up hundreds of free classes, code snippets, arguments for this method of optimization or the other, the famous disposable first system seems less and less necessary, to the point of being quaint, a bizarre artifact from software-prehistorical times, before the “agile revolution.” And, in the vast majority of cases, it probably isn’t necessary… Sometimes, though, you’re going to get a really high-level design problem.
“The map is not the territory.” - Alfred Korzybski
So, here’s the amazing way in which agile methods actually end up owning a canonical piece of waterfall wisdom: Imagine, please, that you’re surrounded by people who are used to being able to solve problems with certainty and you have to acknowledge that nobody really has any idea how to design for the domain of a given problem. The only way to actually see what’s going to work here is to throw it in front of users (iterative, user-driven development, right? New-skool!) But throw what?
…the throw-away first system. Only now, the question isn’t whether the implementation is the right one, it’s whether the design was answering the right question in the first place. Which you can’t know until you try. Which is why, among other things, that even at the eight-count, you should never, ever, count Fred Brooks out.
