A place to discuss Joel on Software. Now closed.
This community works best when people use their real names. Please register for a free account.
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot
The Old Forum
Albert D. Kallal
I read the document "The Project Aardvark Spec".
It is such a mix of requirements, design and implementation that doesn't show clear and well organized thought process and lack methodical work flow.
Friday, August 19, 2005
The fast is that requirements, design and implementation ARE mixed in the "reality domain".
I came to software engineering from a hardware background. I used to be a systems engineer on big audio systems - ie systems that spanned whole buildings and involved many miles of cabling, as well as a number of indivdual bespoke boxes that had to be designed and built. Complexity was an issue here, as is planning. It takes a long time to get that wire in place and build that equipment, and if you don't know damn well what you need before you start, you will be well and truly screwed as you approach your delivery date. Mostly we did get things built on time and on budget, and I firmly believe that this was down to the working methods we were taught.
When I started in that business, the first thing impressed on me was to begin by trying to write a short "system description". It might only be 2 pages long to start - as the process continued, it would grow, but usually not over 20 pages.
There was never any mention of keeping requirements, implementation and design seperate. The emphasis was on brevity, clarity, and describing what the system dis, and how it did it. You cannot really seperate the what from the how. The what by itself is called a "wish list". The how is called a "technical manual". The point at this stage is to conceive the system, what you will make it do and how you will do that. Once that is done you can move with relative safely into planning and organising the workload.
Later in life I moved into software, and worked on other projects. I began to see specs so long that noone could possibly read and understand them without already breaking the timescale for the project, and yet which failed to describe essential aspects of how the system worked (because that's "implementation"). These were invariably linked to projects which overran significantly, and often never quite did what they were intended to.
If you don't know where you are going before you set out, you have little chance of getting there.
It's quite heartening for me to see a spec of the type I continue to swear by, and maybe even more so if it goes against some of the prevailing idiocy of software engineering academia. If it gets good products built on time, it speaks for itself.
All hail BDUF!
That's all well and good, but that document really isn't a BD, it may be UF, but it's not a BD!
Friday, August 19, 2005
who cares? what's your definition of "big"?
I read it as meaning "have the big picture up front". Not produce a "big document".
I already see a number of threads below this which are all about whether X is big, or agile, or whatever. Life is far, far too short. It all reminds me of people having "what is jazz" arguments. There's just good engineering and bad engineering.
"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.”
Unfortunately, looking at his spec., it seems to bear little relation to the type of BDUF that XP and other agile programmers inveigh against. Let's look at some quotes, and see whether they fall under the BDUF or agile camps.
"This specification is simply a starting point for the design of Aardvark 1.0, not a final blueprint. As we
start to build the product, we’ll discover a lot of things that won’t work exactly as planned. We’ll invent
new features, we’ll change things, we’ll refine the wording, etc. We’ll try to keep the spec up to date as
things change. By no means should you consider this spec to be some kind of holy, cast-in-stone law."
Sure sounds agile to me!
"The details of payment amounts and payment options still needs to be worked out."
Hm. Something not being designed up front, but left for later, because the developers are confident they'll be able to deal with it later? I'd say agile.
"Both EXE’s connect to the reflector. Until both parties are connected, they display a message saying,
approximately, “Waiting for your party to connect.” They also provide instructions for what the other
person needs to do, in case the other person gets screwed up."
Hm. Not even actual message text, much less a screen mockup. Which makes sense, because that's not hard to design later, and you probably want to try it out on a few people in your target audience before you finalize the design. Certainly seems agile.
There are implementation notes scattered throughout the document, but they're few and far between; it looks like a lot of the detailed design is being left to the developer. Nothing wrong with that, if you have developers that are reasonably intelligent, but doesn't really seem BDUF.
I notice that there's no design at all for even the general structure of the program, much less getting into typical BDUF stuff like listing all of the modules, designing the internal interfaces, and so on. Again very agile.
As an XP coach, if someone came to me with such a document, I'd say that it would be a great start to an XP project. If they didn't have something like this, I'd sit down with them for however long it took (probably a couple of days, for something this size) and work out such a document. Then I'd go and do further design work for the program itself, making and estimating stories for the various parts. (This could easily be a day or two worth of work as well.)
It's not uncommon in larger XP projects, say one that would be 6-8 months long, to go and do a full week of nothing but making and estimating stories, which is essentially design work, without writing a single line of code.
So I'm mystified by Joel saying he preferrs BDUF to XP-type stuff, but actually taking an approach that any XP team would applaud. What's going on here? Perhaps it's a lack of understanding of XP.
Why is it that any criticism of XP is infallibly characterized by its proponents as a "lack of understanding" of XP?
Does these people really believe that to understand XP is invariably to love it?
In my experience, XP has good and original ideas in it.
Unfortunately, the good ideas are not original, and the original ideas are not good.
Friday, August 19, 2005
"Why is it that any criticism of XP is infallibly characterized by its proponents as a "lack of understanding" of XP?"
Xp's a toolbox, not a process. XP bods don't criticise it for its missing tools; we just go out and find them somewhere else (SCRUM, common sense, etc.).
People who criticise XP often do so because they think of it as a process, rather than a toolbox, and spot the incompleteness of the process. This betrays a lack of understanding. We know it's incomplete. It doesn't mean that it isn't an amazing toolbox.
With respect to Joel's arguments, XP has plenty of tools for design-up-front. The planning game is one of them. Most XP people I know have also slipped domain driven design or similar into their toolboxes to make up for the occasional lack of a heavyweight spanner. Here we run a slightly longer design phase to give people a grasp of the budget required for a project. Joel's chosen to write a loose spec.
It doesn't stop us using all of XP's tools too.
Friday, August 19, 2005
well, that was an article of about ... what .. 500 words by Joel? (haven't counted). Of which this phrase:
"no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that."
... about 20 words touches on his apparent misconceptions over what XP is or isn't. (I say apparent because I just don't know, or care that much, frankly.)
Now weight of content is obviously not proportional to word count, but even so, the weight of comment on these pages seems to focus quite diproportionately on the near-mortal wound his sprolsky-ness attempted to inflict on XP.
It all seems a bit out of proportion. I can't help feeling that you'd all have been saying the same stuff about top down, or structured, or whatever, a few years back. I'm sure that XP has valuable things to offer. But does it really matter THAT much? (That is, that much more than the useful and valuable content that may be in that article - if youi care to notice ...)
Curt Sampson, great rundown. I think it is clear Joel messed up on that BDUF/XP statement. I wish he'd comment on that now that this discussion has gone on all week. On the other hand, he is now in a position where he can make an ill-conceived but controversial jab like this and cause a great deal of discussion and attention, so it is not in his best interest to revisit it.
Friday, August 19, 2005
XP, for some reason, seems at least a little bit more (perhaps a lot more) subject to straw-man arguments than other things out there. A perfect example was a book I once saw (the name entirely escapes me, sorry) claiming to point out many problems with XP. It often did this by telling little stories that pointed out nothing but that really stupid people who don't know XP can screw things up badly.
Joel made a statment implying someting about XP that is demonstrably and obviously (to those who know XP reasonably well) false. We should let this go uncommented-upon?
I don't really care if you use XP in your project. In fact, don't; that will just increase my competitiveness if we ever happen to be competing in similar circumstances. But I don't like to see comments going around that will mislead people about what XP really is, and what it does or doesn't allow, because that may put off someone that I may want to hire one day.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz