[AccessD] OT(?): Big Design Up Front (BDUF) vs. XP any comments, ideas, experience?

Arthur Fuller artful at rogers.com
Thu Aug 18 11:21:00 CDT 2005


About a decade ago I headed a development team for an insurance company.
Half the job was to take some mainframe programmers and acquaint them with
PC development tools and best practices. XP was not a big thing then, but I
improvised an approximation of it at that time. I started with 2
programmers, and had them sit with me as I coded. They were learning lots of
things at once -- syntax, editor keystrokes, shortcuts, etc. At first I was
moving so quickly that they couldn't even see what I was doing (particularly
in the editor itself), but a few explanations and we were over that hump.
The hardest thing to teach them was "1 proc does exactly one thing"... No,
upon reflection, the hardest thing to teach them was "avoid coding until the
last possible moment." The first two programmers then took on a programmer
each and repeated the "semester", as it were, and then those two took on a
programmer each. By the end of the project, we had a team of capable
programmers, and we stuck to the rule of "two programmers per keyboard" all
the way through the project. It worked brilliantly -- about equivalent to
debugging while writing the code. The second programmer might watch the
first start a recursive routine and say, "Hey, wait, let's break it out into
two routines and avoid the recursion problems." They might kick it around
for a bit before choosing one or the other approach, and also document why
they elected that choice.

I am _way_ big on BDUF! Avoid coding until the last possible moment --
that's my motto. I started out as a cowboy coder, but no more. I spend a
_lot_ of time db-design tools such as DeZign, and I don't even begin
creating sample data until I've been through about 3 revisions of the given
DB design. Then I write use-cases describing each function the software must
perform, using English not pseudo-code -- in fact, I have learned to avoid
any specific references to tables, and instead to write such statements as,
"When the user selects a product and quantity she wishes to buy, place a
5-minute hold on that quantity. When the user's credit card payment is
authorized, deplete inventory by the specified quantity and remove the
hold."

Once the DB design is finalized, and the purpose of each table, view, sproc
and UDF described, then even a relatively new hire can take the spec
described above and implement it easily. In the example I gave, there are
the following steps:

1. Obtain the product ID and desired quantity
2. Check to see said quantity exists (we'll sidestep the issue of
back-orders for now).
3. Place a hold on said quantity, with a timer mechanism of some sort (SQL
Server is great at this, much better than an Access timer).
4. Obtain the credit card info, fire it off and check the return status.
5. If the payment went through, deplete the quantity available. 
6. Remove the hold.

Each of these steps can be reduced to exactly one procedure. You (as
manager) could even assign each step to a different programmer. So long as
the DB design is solid, there should be no issues.

I haven't read either book you mentioned, but I'll put them on my list of
things to read.

Arthur

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: August 18, 2005 5:50 AM
To: !DBA-MAIN
Subject: [AccessD] OT(?): Big Design Up Front (BDUF) vs. XP any
comments,ideas, experience?

Hi All,

I've got this this today from JoelOnSoftware subscription list:

<<<<<<
"As I worked through the screens that would be needed to allow
either party to initiate the process, I realized that Aardvark
would be just as useful, and radically simpler, if the helper
was required to start the whole process. Making this change in
the spec took an hour or two. If we had made this change in code,
it would have added weeks to the schedule. 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."

- From my latest article:

  The Project Aardvark Spec
  http://www.joelonsoftware.com/articles/AardvarkSpec.html
>>>>>
No comments.

It happened that I'm currently reading:

"Microsoft Object Thinking"
by David West
ISBN:0735619654
Microsoft Press C 2004

and

"Extreme Programming Adventures in C# "
by Ron Jeffries
ISBN:0735619492
Microsoft Press C 2004

These two books are from Microsoft Press and they have a lot of useful
information on eXterme Programming, Unit Testing and Classical(Behavioral)
vs. currently existing in most implementations "real life" UML-based(RUP)
OOD&P.

When MS Press publishes books on such more computer-science than
used in real life projects subjects then they are very probably "cultivating
the ground" for the soon to become true "dreams". (I remember I watched a
movie "Microsoft, Year 2004"(form MS of course) somewhere in year 1995 or
so - and as I see now their by that time science-fiction is now real-life,
exactly in year 2004-2005.

I must say I impressed with both books (and there are just a few technical
books I liked because most of them are just "chewing" MSDN or other docs
without almost any new ideas).
The more I read them the more I like them and I see a lot of sense in what
is written in them and I see a lot of my own ideas and experience are there
too.  I'm glad my thinking is in the mainstream (of course what they say is
much more elaborated and thought through and based on their own rich
experience).

So my guess/thinking is that XP, Unit Testing and Behavioral (Extreme)
OOD&P are becoming mainstream for real-life development of the projects of
any size - in fact as authors of these books state (based on  their
experience)  that the stuff they are writing about is the "only" agile way
to solve the challenges of nowadays customers and projects requests. And
they are not fanatics I think - they base their writing on deep analysis of
all the previous 50 years experience in software development and not only in
software -  "Microsoft Object Thinking"  is more philosophical than
technical book and it has quotes from Plato (year 400 B.C.) - these quotes
are used to explain how to "attack" complicated/vague projects'
requirements...


What do you think about the subject and related issues?

Do we need Access/VBA Unit Testing added here -
http://opensourcetesting.org/unit_misc.php (Open source tools for software
testing professionals) - it can be done - does it make sense?

Shamil

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list