when does BDUF and waterfall work?

For years we used Waterfall methodologies and built amazing systems.
These methodologies should be tools to use when needed. Are there still
reasons to use these methodologies? Are agile approaches the new super
hammer?

Here is my take. We had reasons for big design up front. The reasons
varied from technical to territorial.

Reasons for BDUF: (No particular order)
1) Build times were submitted and it could be days before it was
loaded/compiled/ran, etc.
2) Debuggers where weak and it was more efficient to avoid bugs than
look for bugs.
3) Software management was emerging as a business and manage means
control.
4) Management flexed its new found power and said it will hold
developers accountable.
5) Developement needed a contract to be used in defense. (Development
new that all requirements are not known up front but management
believed that if more activities were performed then all of the
requirements could be discovered)
6) Software businesses emerge with many departments and with all of
these departments and people the business requires efficient use of the
human resources discounting the efficient development of code. This
means keeping marketing people busy at the expense of development. This
means keeping HR people busy at the expense of development. This means
keeping managers busy buzzy around at the expense of development. (Is
this enough to get a rise out of someone?)

In my humble opinion (IMHO) I feel that the reasons I list as (1) and
(2) are the most important. If there is something expensive to do (i.e.
build time) then do activities that are less expensive.


So in todays world when is BDUF useful. Suppose you will have only one
meeting with the customer. You had better get all you can get from that
meeting. Gather requirements. Create paper prototypes and present them
to entice further requirements from the customer. Because, what you
walk away with is what you have.
Can you think of another example?

Geoff

"Gilligan" <sirgilligan@yahoo.com> wrote in message
news:1105547030.938839.27120@c13g2000cwb.googlegroups.com...
> For years we used Waterfall methodologies and built amazing systems.
> These methodologies should be tools to use when needed. Are there still
> reasons to use these methodologies? Are agile approaches the new super
> hammer?
>
> Here is my take. We had reasons for big design up front. The reasons
> varied from technical to territorial.
>
> Reasons for BDUF: (No particular order)
> 1) Build times were submitted and it could be days before it was
> loaded/compiled/ran, etc.
> 2) Debuggers where weak and it was more efficient to avoid bugs than
> look for bugs.
> 3) Software management was emerging as a business and manage means
> control.
> 4) Management flexed its new found power and said it will hold
> developers accountable.
> 5) Developement needed a contract to be used in defense. (Development
> new that all requirements are not known up front but management
> believed that if more activities were performed then all of the
> requirements could be discovered)
> 6) Software businesses emerge with many departments and with all of
> these departments and people the business requires efficient use of the
> human resources discounting the efficient development of code. This
> means keeping marketing people busy at the expense of development. This
> means keeping HR people busy at the expense of development. This means
> keeping managers busy buzzy around at the expense of development. (Is
> this enough to get a rise out of someone?)
>
> In my humble opinion (IMHO) I feel that the reasons I list as (1) and
> (2) are the most important. If there is something expensive to do (i.e.
> build time) then do activities that are less expensive.
>
>
> So in todays world when is BDUF useful. Suppose you will have only one
> meeting with the customer. You had better get all you can get from that
> meeting. Gather requirements. Create paper prototypes and present them
> to entice further requirements from the customer. Because, what you
> walk away with is what you have.
> Can you think of another example?

Well, item 1 (long lead times to build and test) is a historical
fact, which thankfully is exactly that: historical. A queueing theory
analysis would show that it necessarilly forces big batches: doing
a lot of work to take advantage of the big batch nature of the
compile and test system.

Item 2 turns out to be a red herring. One of the most consistent,
and most surprising, things to come out of experiance in using
Test Driven Development is that people use the debuggers less,
to the point where they frequently forget how. A frequent need to
use a debugger is a sign of poor development practices. (Smalltalk
is somewhat of an anomaly since you can change code and restart
from the debugger.)

3 through 6 are all organizational issues. Many of them are
forced by the nature of big, hierarchical organizations; one
doesn't have to work that way, nor do organizations have
to work that way.

What's going on is a simple (lack of) recognition that when
you remove one bottleneck (long lead time for access to
compile and test resources), the bottleneck moves somewhere
else, and sometimes it makes sense to reorganize the process
to take advantage of the new facilities.

John Roth


>
> Geoff
>

Thanks for your comments.

In TDD you find that "people" use debuggers less. Please expound.
Which people?
How do you quantify less?

I find that when it is necessary to show behavior to another developer
(we are going to pair on something) that running the tests and stepping
through the code is a great way. The debugger is essential and used a
lot.

How did you mean your statement?

Thanks,
Geoff

"Gilligan" <sirgilligan@yahoo.com> wrote in message
news:1105558910.231647.103450@f14g2000cwb.googlegroups.com...
> Thanks for your comments.
>
> In TDD you find that "people" use debuggers less. Please expound.
> Which people?
> How do you quantify less?
>
> I find that when it is necessary to show behavior to another developer
> (we are going to pair on something) that running the tests and stepping
> through the code is a great way. The debugger is essential and used a
> lot.
>
> How did you mean your statement?

It's a general observation of people who use TDD a lot.
The don't find a real need to use the debugger because
problems show up when you run the test suite, which
you do after every edit that you change something.

Since it ran correctly before the last change, it's the last
change that caused the failing tests. It's usually quite
obvious as to what happened, and if it isn't it's usually
faster to hit undo and do something different.

If you find that the debugger helps you, fine. There are
people that like it.

John Roth

>
> Thanks,
> Geoff
>

On 12 Jan 2005 11:41:50 -0800, "Gilligan" <sirgilligan@yahoo.com>
wrote:

>Thanks for your comments.
>
>In TDD you find that "people" use debuggers less. Please expound.
>Which people?

I'm not the OP, but "people" to me means some unidentified subset of
the people I talk to who have taken up TDD. A very common statement is
that they no longer need to do debugging.

>How do you quantify less?

I have programmed in Ruby for several years now, off and on, and I
don't even know how to use the debugger.

In Smalltalk I use the debugger as a code entry tool, because it will
automatically put you in the write place to type in the method or make
the change, but I use it almost never to "debug", i.e. to look at
objects, much less step.
>
>I find that when it is necessary to show behavior to another developer
>(we are going to pair on something) that running the tests and stepping
>through the code is a great way. The debugger is essential and used a
>lot.

If code can only be understood through stepping, I would be concerned
about its clarity and the quality of its design. I'm not saying that
it is automatically bad, but I'd be looking pretty hard at trying to
make it more clear. We should not have to step code to understand it,
in my opinion.

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Wed, 12 Jan 2005 19:39:26 -0500, Ron Jeffries <ronjeffries@acm.org>
wrote:

>In Smalltalk I use the debugger as a code entry tool, because it will
>automatically put you in the write place to type in the method or make
>the change, but I use it almost never to "debug", i.e. to look at
>objects, much less step.

I guess I didn't right the write thing up there. :)

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

>>If code can only be understood through stepping, I would be concerned
about its clarity and the quality of its design. I'm not saying that
it is automatically bad, but I'd be looking pretty hard at trying to
make it more clear. We should not have to step code to understand it,
in my opinion.

I will focus on the word "only" in your response. It is not the only
way. But the debugger is a great tool. It keeps context for you so that
the humans are not burdened. It shows all of the state for you so that
you don't have to keep that in your head. It follows the paths that you
want (either the natural code flow or move the PC) so it is like a
"reader" in the old reviews we used to do. You can stop during the
"tutorial" and go to lunch and it is easy to look at the state and
remember where you were. It is a tool.

When you read code you read it one step at a time. Don't you? Depending
on your current role in development you may have to read someones code.
To take your comment to the extreme it would be like saying, "We should
not have to read code to understand it." That is fine, the unit tests
"understand" the code and whats to understand if the code works? Lots
of things. You may be refactoring a piece that you are not aware of.
You have to read the code to understand it, don't you? If the original
programmer has changed jobs (yet again) you can not ask for human
explination and if he was there would you trust his memory or would you
run his tests and read/step through them to get the picture?

How do you do it if my approach isn't write (he he pun from your
followup)?

Geoff
aka Gilligan
aka Maverick
aka Trouble!

"Gilligan" <geoffrey.slinker@gmail.com> wrote in message
news:1105639619.069099.190590@z14g2000cwz.googlegroups.com...
> To take your comment to the extreme it would be like saying, "We should
> not have to read code to understand it."

Actually the point I get from Ron's comment is that "We should understand
the code by reading it".

Good examples that I have seen of this recently are in the Refactoring to
Patterns book by Joshua Kerievsky.

Cheers Shane

http://www.industriallogic.com/xp/refactoring/

As I talk to people I think I have found some of the things that cause
me to do the things I do.

A couple of which I haven't mentioned before is that I am slightly
dislexic (sp?). If I look at number quickly I will transpose some of
them. Because of this I try to be ultra focused. I guess I have learned
to hide my limp.

Also, I do too many things and the contexts get all jumbled up.
Maybe I am a handicapped programmer!

On 12 Jan 2005 08:23:50 -0800, "Gilligan" <sirgilligan@yahoo.com>
wrote:

>For years we used Waterfall methodologies and built amazing systems.

Are you speaking of yourself, or are you speaking of the industry.

The statistics for the industries use of waterfall are appalling.
Waterfall project failed by 2:1 or more.  Craig Larman's wrote a book
on this topic recently.  You might want to glance through the 50 pages
of evidence about the fiasco that Waterfall really is.

Agile and Iterative Development: A Manager's Guide
http://www.amazon.com/exec/obidos/A...objectmentorinc

>These methodologies should be tools to use when needed. Are there still
>reasons to use these methodologies? Are agile approaches the new super
>hammer?

Agile methods are the *old* super hammer.  They predate waterfall
significantly -- though they've only been given the name "agile"
recently, and their practices have only been refined in the last
decade.

>So in todays world when is BDUF useful.

A formalized design phase with formalized artifacts is never useful
IMHO.

>Suppose you will have only one meeting with the customer.

You will fail.  So make sure the contract is time and materials.

>You had better get all you can get from that
>meeting. Gather requirements. Create paper prototypes and present them
>to entice further requirements from the customer. Because, what you
>walk away with is what you have.
>Can you think of another example?

And even then I would use an agile process.  I would have someone
internal represent the customer, spending the vast bulk of their time
trying to understand the customer's needs and the features that will
address them.


-----
Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo