!title Joel On Xp (Again) Recently Joel wrote: http://www.joelonsoftware.com/articles/AardvarkSpec.html In this article Joel talks about the 20-page functional spec he wrote for his Aardvark project. He notes that by thinking through the spec he was able to avoid a number of problems that could have delayed his project. From this he concludes: !* Excerpt. ''"I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that."'' *! Oh Joel! First of all a 20 page function spec (with a big coding standards section in the middle) is not a BIG DESIGN UP FRONT. A BDUF is 1000 pages of UML diagrams that plan out every intimate little detail of how the system will be built, before any code is written. If you doubt that companies write such silly tomes, let me correct you. Some companies ''glory'' in making sure that absolutely every class is described in a class diagram, and every method is described in interaction diagrams. Some development teams describe the entire static structure and the entire execution flow of their projects, before writing a line of code. THAT is BDUF, Joel. And it's completely insane. No, Joel, your little functional spec was just a little functional spec. It was a good document, and you were right to write it. I would not be surprised if an XP team wrote a document like this; nor would I yell at them for blasphemous behavior. Writing a little spec like this is perfectly appropriate. If you read the XP/Agile literature carefully you will find that XP demands that a document like this be written. Yes, it's true that XP wants the document written incrementally. It's true that XP does not want the '''whole''' document written in detail up front. On the other hand XP does want each iteration's worth of the spec written in ''hideous'' detail, in the form of automated acceptance tests. What's more, XP ''does'' want a rough outline of the document (i.e. the release plan) written before the iterations begin. Oh there are some differences for sure. An XP team would be more likely to write the release plan on a set of index cards. They would be more likely to formalize the requirements at the beginning of each iteration by writing FitNesse tests (See www.fitnesse.org). They would be more likely to work out a lot of the functional behavior in CRC sessions or conversation, before writing the acceptance tests. On the other hand an XP customer (like you might be) might very well write a document in exactly the form you chose, if there was a need (like communicating with a bunch of summer interns that you couldn't sit down and work with). XP doesn't tell you not to write a document like this. XP simply tells you to convert it from a outline to a formal document in increments, which are usually one or two weeks long. Joel, You write a lot of good stuff. It would be even better if, before you bashed XP any more, you actually took the time to understand what XP is. You might find that the XP community is comprised not of a bunch of wild-eyed "fanatics", but of a group of sincere old-timers who simply want to teach the industry (these kids nowadays!) how to take small, careful steps. Uncle Bob. ---- !* Sun, 28 Aug 2005 09:02:49, Michael Feathers, Spec or Design? I had many of the same thoughts when I read Joel's thing. It's a spec not a design, and frankly, and if it had been written as a set of FIT pages, he'd have had the added benefit of always knowing how much was done during development. *! !* Sun, 4 Sep 2005 23:30:24, Ravi V, Big Design Up Front Just curious. If you ask the run of the mill XP practitioner, how many would feel that Joel's attempt was in fact an example of Big Design Up Front? Many XP enthusiasts assume that no Big Design Up Front is the same as No Design Up Front. *! !* Tue, 6 Sep 2005 15:34:36, Patrick Welsh, BDUF Ravi's question is useful. Uncle Bob's article helps clarify something that has not always been clear to me and, I suspect, other agile practitioners. How much DUF constitutes BDUF? How much Design Up Front is just enough, and how much is too much? If we begin with FIT tests, we can answer that question quickly and straightforwardly. The original XP literature did not make it clear (to me anyway) exactly how and where to draw that DUF line. *! !* Thu, 8 Sep 2005 14:29:20, Michael Feathers, DUF I don't mind DUF as long as people allow themselves to change their mind when better ideas come along. The sad thing is that DUF often turns into tunnel vision.. unless you're used to looking for alternatives, you just don't see them. There's something profound in learning that you can work knowing only one requirement at a time and still end up with a good architecture. To me, it's a experience every developer should have.. it's sort of like the big scene that you see at the end of a martial arts movie where the fighter has been trained by some master and foes come out of the woodwork, from all directions. When you are well-trained you know how to deal with the unexpected and you are much stronger because of it. *! !* Wed, 14 Sep 2005 18:08:54, Sri, Eye Opener I am a methodology entusisast - a novice thoug and have had a very different opinion about XP reading articels similar to the one of Joels pointed out here. This article has been an eye opener and really explains the perspective of the XP guys. Also one other thing that I feel reading about the methodologies - is that there is no 'one size fits all' as far as methodologies go. No methodology works in all situations - based on various factors related to the project, users, company the choice of a methodolgy need to be made. *! !* Fri, 9 Dec 2005 15:03:53, Brian Knorr, go back to the manifesto One of the princles under the Agile Manifesto (http://agilemanifesto.org/principles.html) is the following: - Working software is the primary measure of progress So if you are caught up in DUF or BDUF you really haven't made any progress. It's best to get to working software as soon as possible. *!
Use alt+s (Windows) or control+s (Mac OS X) to save your changes. Or, tab from the text area to the "Save" button!
Grab the lower-right corner of the text area to increase its size (works with some browsers).