The Joel on Software Discussion Group (CLOSED)

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.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Aardvark Spec

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.
Brad Douglas
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!
Daniel McBrearty Send private email
Friday, August 19, 2005
 
 
That's all well and good, but that document really isn't a BD, it may be UF, but it's not a BD!
Brian
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.
Daniel McBrearty Send private email
Friday, August 19, 2005
 
 
Joel says:

"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.
Curt Sampson Send private email
Friday, August 19, 2005
 
 
BD up front, not BP up front! There's a difference...
Brian
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?

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
 
 
No, to know XP is not to love it, but Joels side remark about XP shows clearly that he's talking out of his behind. XP clearly advocates nailing down a (user) specification of the system to build before starting to code.
Thomas Mäder Send private email
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.
Elizabeth Keogh Send private email
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 ...)
Daniel McBrearty Send private email
Friday, August 19, 2005
 
 
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.
Ben Bryant
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.
Curt Sampson Send private email
Saturday, August 20, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz