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

Agility

Quoting Joel:

"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."

On an Agile or XP project there is generally a Customer's representative on the team, if not the Customer him/herself.

In your situation, Joel, I propose that you are essentially fulfilling the Customer role. You have a clear concept of the problem domain, likely solutions, desired features, etc., etc. No wonder BDUF works for you!
Matt Y. Send private email
Wednesday, August 17, 2005
 
 
I'm a BDUF apostate. I used to be a firm believer, but the simple fact is that my customers don't have the first clue what they really want until they get to play with something that's in the ballpark.
comp.lang.c refugee
Wednesday, August 17, 2005
 
 
I also wouldn't at all consider this spec "big design".  This is a great functional spec.  It essentially has already been broken down into "stories" with priorities on them.  It's not big design, it's knowing what you want.  Big design would be having specified all the classes in the system and how they would interact before you touched any code.  Joel, I think you do agile development without wanting to call it that.  :)

Now, if we can just talk about those horrible coding standards...
John Watson Send private email
Wednesday, August 17, 2005
 
 
"Making this change in the spec took an hour or two." does not maketh a BDUF!

Quote: "There was one big mistake in the spec. When I wrote it I had assumed that port 443, used by the secure (SSL) http protocol,..." would have been a perfect candidate for an XP-like Spike Solution.

Good of Joel to put the specs up for scrutiny but there's nothing there that an XP project wouldn't have. Joel, what's with the XP bashing... are you ashamed that you might be a little bit of an XP-er yourself?
JP
Wednesday, August 17, 2005
 
 
> would have been a perfect candidate for an XP-like Spike Solution.

Spike solutions are far older than XP.
son of parnas
Thursday, August 18, 2005
 
 
Almost everything in XP is older than XP.
JP
Thursday, August 18, 2005
 
 
Unfortunately, Joel doesn't really know what the hell he's talking about re: XP and agile.
Brad Wilson Send private email
Thursday, August 18, 2005
 
 
All good points

(a) Not really big upfront design for the reasons John Watson gave. 

(b) Matt Y is right too, because this is different from many situations I've been in where the customer really isn't sure what they want until they start playing with the system.  In these cases, it's better to take the "Tracer Bullet" approach put forth by the Pragmatic Programmers.

It's different if you can dictate to the customer how something will work or if you already have an accepted framework in place for interaction.

And back to point "a".  Some would consider this big, but I've seen bigger.  Like John, I think this is just spelling how the thing works.  If Agile methodology means running off and writing code before something like this is written,then consider me a BDUF guy too!  (In a lot of my cowoker's minds I AM a BDUF for believing this.)  The sweet spot is to figure out when to stop specifiying and to start coding.

Thanks for making the spec public, Joel.  This is a great learning tool.
Crimson Send private email
Thursday, August 18, 2005
 
 
A 20 page spec for a 3 month project is a great thing!

But it's not BDUF, it's SDUF. (small)
Rich Rogers
Thursday, August 18, 2005
 
 
I think the common theme is correct really, this isn't Big Design Up Front, its Clear Requirements Upfront, which still doesn't make a nice pretty acronym but never mind.

The BDUF sins are over specification and over analysis but the greatest sin of all isn't perpetrated by the people that manufacture volumes of specifications its perpetrated by the people that manage the implementation of those specifications.

If you can't produce a flexible implementation that can take a major unforseen event and incorporate it without dismantling or invalidating a lot of other work then you have no business attempting to implement anything more complicated than taking a cork out of a bottle.

The instance in Aardvark shows that although there was an error in the intial investigation (and there always is one at least with teeth on it), it was possible to get around the problem and get a solution out which didn't break the bank.  Although 10% is a major slice of development at the end of the cycle (remember the Zeno theorem of software development, its never finished just insufficiently tested and the further you go along the further the goal appears), and that suggests there was either some major refactoring or it was just difficult and needed a slew of testing.

When confronted by a BDUF leviathan one has to go guerilla, yes that's the requirements, but here's our response and its leaner and meaner than yours.

Developing Software is not the same as Architecture for Buildings and making that mistake has been the cause of most of the Death March events.
Simon Lucy Send private email
Thursday, August 18, 2005
 
 
Crimson wrote:
"The sweet spot is to figure out when to stop specifiying and to start coding."

You can't prevent all code re-writes and bug fixes, but I found it shocking to descover how many can be prevented simply by learning from past mistakes (reports of 50% - 70% exist). One rule of thumb is to only stop writing the spec if you are fairly sure you are not going to repeat any past mistakes.
Eddy Send private email
Thursday, August 18, 2005
 
 
> I'm a BDUF apostate. I used to be a firm believer, but
> the simple fact is that my customers don't have the
> first clue what they really want until they get to
> play with something that's in the ballpark.

I've found (during my admittedly limited experience) that customers know what they want, but you have to draw it out of them. They're usually awful at drawing up a spec, which sometimes, unbelievably, they're asked to do. When they start specifying what kind of buttons are on the screen and the types of fields in databases it turns into a complete disaster.

OTOH, when a programmer/architect starts deciding or assuming that they know what people want it also turns disastrous.

The spec I've worked on that worked the best worked out because:

1) The customer interviewed potential users and sent around questionnaires.
2) The customer didn't write a full spec - just an outline of the problem. I drew up a rough design from that - gave them a powerpoint presentation on it and they completely changed half of it.
3) I rewrote it and we did the same again and then I started the application.

It worked because the customer and I shared an identical, accurate and clear conception of what the application would be like.
Colm O'Connor Send private email
Thursday, August 18, 2005
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz