Misunderstanding Agile Design

Aug 17, 2005 software methodologies suggest edit

Now I like to take shots at myself for producing drivel now and then, but today, I’m going to take a shot at someone else’s drivel. I really should be working right now, but I really need to stop a moment to respond to some FUD. Once again, Joel Spolsky sprays more ignorance on his readership with this quote…

I cant tell you how strongly I believe in Big Design Up Front (BDUF), which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and Im proud to use it, no matter what the XP fanatics claim. Theyre just wrong on this point and I cant be any clearer than that.

First, as Brad Wilson mentions, Agile does not mean no design.

The primary mantra of agile methodologies is to do only what is necessary, and no more. For a product company like Joel’s FogCreek, a functional spec is absolutely necessary. (As an aside, I’m a fan of his Painless Functional Specifications Series and have used it as a template for functional specs on several projects). They are not treading new ground with their products and the requirements appear to be very stable from release to release. For example, for CoPilot, Joel dictated the requirements which the interns implemented.

However, I’d point out that the spec he published for all to see is a great example of doing what is necessary and no more. Notice he didn’t list out the specific database tables nor class diagrams. This spec is not an example of big design up front. It is a great example of doing just enough design up front as necessary. How very agile of you Joel and you weren’t even trying.

The second fallacy is that Joel takes his narrow product-based experience and applies it to all of software development. When you are the one who gets to define requirements and your project does not explore new ground, Big Design Up Front hands down can work. But try applying that approach to a client project and watch with horror as three months into the project, the client changes his mind on a feature and leaves you with a hunking mass of outdated and useless UML diagrams you spent eighty man-hours producing.

Agile methodologies are designed to manage change. When you don’t have change to worry about, you can resort to BDUF (though even then I’d only do what is necessary). Agile methodologies weren’t designed to handle developing the software for the Space Shuttle. Requirements are fixed and hardly change in such a project.

But most real world projects have a lot of change. Where does that change come from? The client! There are other sources of change during a project’s lifecycle as well, such as new technologies and from new ideas gained during the project, but the majority of it comes from the client changing his or her mind.

Your typical client knows jack shit about how software is really developed. Yet you expect the client to be able to express extremely detailed requirements for what he or she wants? Might as well hand her a keyboard and tell her to write the code for what she wants. Would you try that with a home builder?

“Hey, I’ve written you a list of exactly how I want my house to be. I’ll be back in a month to see the finished product. Can’t wait!”

I sure hope you wouldn’t. Most likely you’d want to check in every now and then and see how things are going. And as you see the house develop, you might change your mind about a few things.

Developing software for a client is very much like that. A client often doesn’t know what she wants until she sees it. As the project unfolds, the client (and development team) learns more and more about the product and starts to realize that some of her initial requirements don’t really make sense, while also recognizing that there are other requirements that she hadn’t thought of, but your demo reminded her.

Try BDUF on a project like that, and you’re setting yourself up for disappointment and failure. That’s where an agile methodology really shines. Divide the project up in iterations, do just enough up front high level design to give the system coherency, and then flesh out the design during each iteration via some up front iteration level design and refactoring. Again, do just enough design as necessary, but no more.

Found a typo or mistake in the post? suggest edit

Comments

8 responses

Melissa • August 18th, 2005
In the interest of full disclosure, I'd like to announce immediately that when it comes to software, hardware, and the production, understanding, and - I'll be honest - competent usage thereof, I'm just about one notch above Ned Ludd.

What I really wanted to applaud was your carefully liberal sensibilities:

<blockquote> "a client often doesn't know what she wants until she sees it." </blockquote>

And then I got to thinking...maybe that's actually a bit backhanded, in its own innocent way, loosely equating a female client with indecisiveness and lack of forethought. And then I figured I'd give you the benefit of the doubt, 'cause I've been reading this here weblog for a considerable length of time, and you seem like a stand-up fellow.

And while I'm opining on things about which I have nearly zero domain knowledge and appreciably less experience, I'd like to say that I tend to agree with you re: agile design methodologies. And while I don't know Old Boy personally, I've read enough of his writing to say that, to my mind, Joel just likes to write with conviction, irrespective of the matter at hand. He probably has strong opinions about light butter/no butter/movie theater butter on his heat-expanded maize kernels, and he could probably write a persuasive as hell argument for his position and the more suggestable among us would immediately agree and get on their knees to show their appreciation for Joel's relieving them of their obligation to think for themselves. Its admirable, really, but, yeah, sometimes he's totally off-base. In this particular case, I think that Joel is just not being articulate enough in his thoughts concerning the distinction between BDUF and Agile Design. The very name "agile design" implies design. Its not that he's wrong, exactly, its that he's writing checks he can't cache.

I'll be here 'till Thursday, tip your waitress.
Melissa • August 18th, 2005
Related,

<A HREF="http://www.martinfowler.com/articles/newMethodology.html">Agility Training For The Less Agile</A>
Melissa • August 18th, 2005
by which I mean...

http://www.martinfowler.com/articles/newMethodology.html
Haacked • August 18th, 2005
Melissa, thanks for giving me the benefit of the doubt. Having gone to a very liberal college, I unfortunately have acquired grave insecurities about using masculine/feminine pronouns.

So I try to switch them up, rather than use the singular/plural mismatch of they/their, which though some say is now acceptable, I can't bring myself to do it intentionally.

I'm going to start inventing my own gender neutral pronouns.

I in no way intended to equate female clients with indecisiveness. ALL clients, regardless of gender, age, sexual preference, hair color, musical tastes, are indecisive. And I don't mean this in a negative way. It's impossible for them to visualize exactly what they want in all its minute detail.
Melissa • August 18th, 2005
On further reflection, perhaps I should have been more transparent with my facetiousness. Of course I knew you were not being negative towards that most fairer of the species. Just giving you a hard time.

Believe it or not, I have designs on starting a software company, despite my lack of knowledge in pretty much all areas, and everything I've read regarding clients and their desires seem to indicate monumental indecisiveness and fickleness (ficklecality?)

I suppose I could have just said I was teasing.
pcomeau • August 18th, 2005
I agree his doc is fairly tight and borders on Agile. Outside of certain technology decisions (e.g. VNC, type of SQL database, etc.), implementation is pretty much left to the development team.

Also as one who used to be in "big corporate development" I remeber requirments templates that were 45 pages long. That does not include any docments required for technical exceptions, test scripts, etc. (all stored as doc templates.) Also each various documents had comittees that would review your project all before development could begin... (and don't get me started on SOX and HIPAA compliance audits...)

So yeah, Joel really doesn't understand BDUF.

Oh well... as mentioned in the other thread, a lot of times he's right, but when he's wrong, he is way off base.
Steve • December 3rd, 2010
It may be that the client doesn't know what they want, but drawing pictures of screens and reports is a lot cheaper than building something and throwing it away. I just built a small database application from scratch and my key document was an ER diagram which I scratched out after a phone conversation with the client. Getting the data structure right is one of the few absolute requirements for a successful application. I still suspect that Agile is loved by people who like to play on computers without regard to the cost to the customer.
Vijay • April 7th, 2011
A typical iterative methodology is what i would say should be adopted in case there is an issue with your business analyst doing a bad job about getting good requirements out of your client, with good design and construction concepts than encourage a free for all culture in an organization where nothing is predictable leave alone the out come including the most important, satisfaction of the customer.