jutopia - Joel is misunderstanding XP and BDUF

[]

Joel is misunderstanding XP and BDUF

[ tirsen ] 06:31, Friday, 19 August 2005

Joel is writing about how much he likes BDUF and in doing so reveals exactly how little he understands of XP and what XP-practitioners refer to as Big Up Front Design or in short BDUF.

Downloading and reading through the linked PDF which is the specification for his Project Aardvark or Copilot reveals a functional specification which is a perfectly sound document to have in a "true" XP project. At ThoughtWorks very few projects start without a document of at least the same magnitude (disregarding maybe from some smaller details). We split it up into stories, estimate and rate them and run it through some clever Excel spreadsheet employing various statistical analysis. Out comes a pretty good estimate of how long the projects going to take and what it's going to cost. We call it inception and it's a perfectly "acceptable" thing to do at an XP project.

It is the next step after that in a typical waterfall project that we skip and go straight to development. This step is what we refer to as BDUF. Here fancy "designers" and "architects" go through the functional specifications and using various CASE tools start designing every single component in the system. Down to each class and method. This is what we call Big Design Up Front and Joel, honestly, not even you would be so crazy to do that.

We wouldn't say you're doing BDUF Joel, you're doing EDUF, Enough Design Up Front. We XPers like to do that too.

I don't agree that an XP project jumps straight into development with no up front design. The team must design a rough high-level view of the architecture so that the team work in the same general direction. This involves coming up with the system metaphor, considering technologies and starting evaluation. I explain this by telling people that XP does do "big" up-front design up-front but doesn't do "small" up-front design.

I've seen projects that have not done this iteration zero work, and the systems have all been messy and hard to work with.

--Nat Pryce, August 19, 2005 05:54 PM

Perhaps part of the problem is the name we gave to what we don't do: "Big Up-front Design." The adjective "big" is open to mis-interpretation; for example, nobody, XPer or not, wants to start any coding on the project without having the "big picture," (often called the 30,000 foot view).

--Curt Sampson, August 20, 2005 04:49 AM

The thing you have to keep in mind with Joel is that he has quite a specific (and limited) experience, and is horribly parochial.
The vast majority his experience is in what is effectively shrink-wrapped software (*), even though the majority of developers work on bespoke software.
[ (*) The juno stuff was a bit different, but still consumer orientated ]

When he writes about what he knows, he's good. But in this case he's writing about something he doesn't know (XP), and most of the literature about it is placed in a context he doesn't know (bespoke development).
If he'd just stuck with what he did know he would have been fine. He could have said "Starting coding before you understand what you want to build is costly" and we would have agreed. Or "one of the greatest contributions you can bring to a software project is a clear vision of what you want to build".
But once he left his area of expertise, and started trying to make comparisons and judgements on XP, he got it all wrong.

Joel will happily admit he has no idea what "corporate programmers" do. I can't help feeling that his articles would be more effective if he remembered that when writing them.

--Tim Vernum, August 20, 2005 02:54 PM