SCRUM and Why the Waterfall Methodology is a Fool's Errand ...
Jeff Sutherland
>
> In Article <30AF37...@vmark.com> Jeff Sutherland writes:
> >... the Waterfall Methodology is fatally
> >flawed and doomed to failure....
>
> Is this news? I was under the impression that this had been
generally
> accepted for at least 20 years.
>
> Scott
It is not news to experienced object-oriented developers. It is
news to a large segment of the MIS community. One of the most
experienced people in the RDBMS community sent me email on this
posting saying the Waterfall method worked flawlessly for him.
At a recent tutorial at an OO Conference, I made the point that
there were a number of companies complaining about not getting
the benefits promising by object technology. In every case that
I have been able to examine closely, they were not using an
iterative/incremental development process (see Pittman, IEEE
Software, Jan 93).
I explained to the attendees that if they use the Waterfall
approach, they can expect to get only minimal productivity gains
using OO technology and there was almost a rebellion in the
room. At least one development manager said he could not adopt
OO if he had to change any of the current (antiquated)
development process.
This is a major issue for the uninitiated and I think the OO
community needs to make it an educational priority whenever we
have the opportunity.
Jeff Sutherland
mailto:jsuth...@vmark.com
http://www.tiac.net/users/jsuth/
Kent Beck
<sco...@bmtech.demon.co.uk> writes:
>
>In Article <30AF37...@vmark.com> Jeff Sutherland writes:
>>... the Waterfall Methodology is fatally
>>flawed and doomed to failure....
>
>Is this news? I was under the impression that this had been generally
>accepted for at least 20 years.
>
>Scott
Then why do some of my clients (at least initially) think that
"iterative development" means "an iteration for analysis, an iteration
for design, ..."? Most development organizations still prefer a
pile-of-paper-based illusion of control to active management of
development risk.
Kent
Michael E. Wesolowski
<snip>
> At a recent tutorial at an OO Conference, I made the point that
> there were a number of companies complaining about not getting
> the benefits promising by object technology. In every case that
> I have been able to examine closely, they were not using an
> iterative/incremental development process (see Pittman, IEEE
> Software, Jan 93).
>
>
I explained to the attendees that if they use the Waterfall
> approach, they can expect to get only minimal productivity gains
> using OO technology and there was almost a rebellion in the
> room. At least one development manager said he could not adopt
> OO if he had to change any of the current (antiquated)
> development process.
>
Excuse my ignorance, but why would you recommend against using the
Waterfull model for OO technology? I've seen this hinted at before but I
don't know the rationale. Thanks.
---------------------------------------------------------------------
Michael Wesolowski (mewe...@freenet.calgary.ab.ca)
Robert C. Martin
Indeed, a major methodologist appears to have the same idea,
Steve Mellor recently said the following in an article in which he
answering Booch with respect to the differences between their methods.
"If you picture the system as a box with the application at the
top, divided into subsystems across the top, and the implementation
at the bottom, then I see you taking slices vertically (ie each slice
covers a piece from top to bottom), and Shlaer-Mellor partitioning
the project horizontally."
--
Robert Martin | Design Consulting | Training courses offered:
Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
2080 Cranbrook Rd. | Tel: (708) 918-1004 | Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
Robert C. Martin
Robert C. Martin
>
> I explained to the attendees that if they use the Waterfall
> approach, they can expect to get only minimal productivity gains
> using OO technology and there was almost a rebellion in the
> room. At least one development manager said he could not adopt
> OO if he had to change any of the current (antiquated)
> development process.
This is actually a very serious problem. Many large organizations
have built Waterfall into their accounting system. They "Captialize"
software as it moves through the various waterfall phases. This has
a significant impact on their tax burden.
Clearly they have to change their accounting model in order to move
to iterative development. This is an astounding example of how
interdependent things can become.
Charles C. Lloyd
> At a recent tutorial at an OO Conference, I made the point that
> there were a number of companies complaining about not getting
> the benefits promising by object technology. In every case that
> I have been able to examine closely, they were not using an
> iterative/incremental development process (see Pittman, IEEE
> Software, Jan 93).
I would claim that most compaines are not getting the benefits promised by
OO because they have chosen to use C++ rather than a true OO system
(Smalltalk, Objective-C, to name a couple). The C++ environments I've seen
are not conducive to iterative development, while Smalltalk certainly is.
So while a mindset change is required, so is a change of tools.
Charles.
---
Charles Lloyd cll...@giantleap.com
GiantLeap Software PO Box 8734
(702) 831-4630 Incline Village, NV 89452
Patrick D. Logan
>I would claim that most compaines are not getting the benefits promised by
>OO because they have chosen to use C++ rather than a true OO system
>(Smalltalk, Objective-C, to name a couple). The C++ environments I've seen
>are not conducive to iterative development, while Smalltalk certainly is.
>So while a mindset change is required, so is a change of tools.
In practice, it seems a "true OO" and iterative development environment
does not solve the problem. The problem is the lack of a good design.
"Architecture driven" is the word folks have been using here lately.
There are plenty of horror stories about people using Smalltalk. It is not
because the language or environment are incapable of supporting success.
Because there are plenty of success stories, too, just as there are for C++.
So all things being equal, I agree with the statement above. But I do not
think it is worth parading it around. I think it is better, generally, to
emphasize good design. Then slip in the pitch that says, "By the way, now
that you're designing so well, how'd you like to speed the process up a bit?"
--
mailto:Patrick...@ccm.jf.intel.com
(503) 264-9309, FAX: (503) 264-3375
"Poor design is a major culprit in the software crisis...
..Beyond the tenets of structured programming, few accepted...
standards stipulate what software systems should be like [in] detail..."
-IEEE Computer, August 1995, Bruce W. Weide
Jeff Sutherland
>Excuse my ignorance, but why would you recommend against using the
>Waterfull model for OO technology? I've seen this hinted at before but I
>don't know the rationale. Thanks.
There has been a lot posted here before on this. You can surf to my Home
Page to get the latest info and from there to my SCRUM page.
Jeff Sutherland
Mailto:jsuth...@vmark.com
http://www.tiac.net/users/jsuth/
(Object Studio 5.0, a better way to do C++ development!)
Robert C. Martin
>
> Excuse my ignorance, but why would you recommend against using the
> Waterfull model for OO technology? I've seen this hinted at before but I
> don't know the rationale. Thanks.
>
The Waterfall method first became important about 30 years ago. At
that time, most projects were very small. A 10,000 line program
weighed a good 40 pounds, and was too large to carry down the hall
to the card reader.
In those days, each engineer did what was right in his own eyes. There
was not "method" for producing software, and none was really needed
in most cases.
However, as projects became more and more complex, some kind of
management scheme was needed to partition the project into measurable
milestones. The division between analysis, design and implementation
was already understood, so it was natural to formalize these activities
into phases, and then to make them entities in a schedule. Managers
could not ask questions such as: "Will you be done with the analysis
on time?"
This worked well for many years. However, there is a built in flaw.
The act of analysis is the act of understanding the problem to be
solved. How does one make any predictions about the schedule of
a project prior to analyzing it (and thus understanding it). For
relatively small projects, gut estimates are reasonable. But as
complexity increases, gut estimates become less and less reliable.
Today, a 10,000 lines program is insignificant. 100,000 lines is
barely respectable. Most of us are working on projects that will
total many hundreds of thousands of lines. Megaline projects are the
rule, not the exception.
How can one predict, with any accuracy at all, how long it will take
to analyse, design and implement a megaline project, prior to having
a reasonable analysis? The task is impossible. This fact is borne
out by the plethora of failures. Last year, Scientific American
published a frightening statistic. The probability of project failure
increases geometically with project complexity. The statistic implied
that there was an asymtote! Thus, there may be an absolute limit
to the complexity we can handle. At least when using Waterfall.
The Waterfall method, as conducted by most organizations today, does
not allow feedback. Errors are corrected in the phase in which they
are found. Analysis errors discovered in the design phase are fixed
in the design, not in the analysis (Many people say that they will
go back and fix the analysis, but this does not take place as a rule).
Moreover, and more importantly, the early phases have no completion
criteria. There is no way to tell if the analysis or design is
actually complete. As a result, they tend to be "finished" on
schedule. This communicates false results to the managers, since
the reality is that the analysis and design are probably not complete
and are probably flawed.
In waterfall, the only deliverable that can be tested for completion
and correctness is the Implementation. And this, of course, is where
we have all the problems.
----
Using the iterative method, we split the project into a series of
vertical slices. Each slice is composed of a small set of project
features. We conduct small waterfalls on each slice, driving the
slice all the way from analysis to implementation.
Upon completing the first slice (which ought to be th most complex
of them all) we have some data. We know how long it took to create
that slice. By extrapolation we can determine how long it will take
to complete the rest of the slice. As slice after slice is completed,
the schedule becomes more and more accurate. Moreover, at the
completion of each slice, we have a valid analysis and design for
that slice. That analysis and design gets fed back into the next
slice.
Thus, the project is subdivided into a set of milestones that have
unambiguous completion criteria. The development process produces
data that managers can use to track and predict the schedule, and
each slice feeds back more information into the next slice.
In short, the difference between Iterative development, and Waterfall
development is the difference between an open-loop and a closed-loop
control system. Closed loop systems (systems that employ feedback) are
generally superior.
vvadl...@vnet.ibm.com
on Wed, 22 Nov 1995 09:59:29 -0600,
"Robert C. Martin" <rma...@oma.com> writes:
>Michael E. Wesolowski wrote:
>>
dd Excuse my ignorance, but why would you recommend against using the
>> Waterfull model for OO technology? I've seen this hinted at before but I
>> don't know the rationale. Thanks.
>>
>
>The Waterfall method first became important about 30 years ago. At
>vertical slices. Each slice is composed of a small set of project
>features. We conduct small waterfalls on each slice, driving the
>slice all the way from analysis to implementation.
>
Splitting the project into a series of vertical slices with a subset
of features is the preferred method in prototyping the product
A quick demonstration of some important aspects of the product developme
scheme which includes all the components of analysis,design and
implementation is what I have seen in many projects I have been involved
with.
>Upon completing the first slice (which ought to be th most complex
>of them all) we have some data. We know how long it took to create
>that slice. By extrapolation we can determine how long it will take
>to complete the rest of the slice. As slice after slice is completed,
However practical experience suggests that this is not a very reliable
indicator of the work yet to be done.
Inevitably the time of integration between slices is underestimated.
New features are thrown in while development cycle is in progress.
>the schedule becomes more and more accurate. Moreover, at the
>completion of each slice, we have a valid analysis and design for
>that slice. That analysis and design gets fed back into the next
>slice.
>
This is true to a very large extent.
>Thus, the project is subdivided into a set of milestones that have
>unambiguous completion criteria. The development process produces
>data that managers can use to track and predict the schedule, and
>each slice feeds back more information into the next slice.
>
>In short, the difference between Iterative development, and Waterfall
>development is the difference between an open-loop and a closed-loop
>control system. Closed loop systems (systems that employ feedback) are
>generally superior.
Not to be picky but to the output of a closed loop system is fed back
through inverse of the plant ( Control systems terminology) and this is
used as a modifier to the input of the original plant.
Well closed loops for Software development projects are no where near
that kind of smooth functioning. I hope to see one someday ;)
Regards,
Vish Vadlamani
>--
>Robert Martin | Design Consulting | Training courses offered:
>Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
>2080 Cranbrook Rd. | Tel: (708) 918-1004 | Mgt. Overview of OOT
>Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
--
___________________________________________________________
| |
Vish Vadlamani | v v |
IBM - FT Networking | v v |
| v |
vvadl...@VNET.IBM.COM | |
________________________________|_________________________|
All opinions expressed are mine only and not those of IBM |
or my employers. |
__________________________________________________________|
Robert C. Martin
I suggest that a process that:
1. Identifies the domains (layers) in the system, as the first step
2. Immediately moves to understand (and document) the dependencies
between the domains
3. Analyzes each domain separately and (relatively) independently
is taking on active management of development risk, through explicit
management of the dependencies between the layers. Further, we
begin this very early on in the development process. Finally I say
for one last time, that such a process is not a waterfall.
Agreed, this is not waterfall. Moreover, most of this is very
traditional OO thinking. Our previous confusion was primarily due to
vocabulary. You were contrasting Booch's vertical slices to your
horizontal slices. But you don't really have horizontal slices (in
terms of Analysis, Design, Implementation). YOu have orthogonal slices
in terms of subject areas.
My only comment here is that you still need vertical slices. It would
be a grave flaw to analyse and develop the subject areas separately.
There is no good way to keep them in sync except to cut vertical slices
through the entire product, touching all the subject areas, and make
those slices deliverables in a schedule. In that way, for each
scheduled deliverable, the subject areas must be in sync. This closes
the loop and staves off the integration nightmare.
Robert C. Martin
Scott A. Whitmire
>I would claim that most compaines are not getting the benefits promised by
>OO because they have chosen to use C++ rather than a true OO system
>(Smalltalk, Objective-C, to name a couple). The C++ environments I've seen
>are not conducive to iterative development, while Smalltalk certainly is.
>So while a mindset change is required, so is a change of tools.
>
Bull!
Scott A. Whitmire sco...@advsysres.com
Advanced Systems Research
25238 127th Avenue SE tel:(206)631-7868
Kent Washington 98031 fax:(206)630-2238
Consultants in object-oriented development and software metrics.
Paul Johnson
>This is actually a very serious problem. Many large organizations
>have built Waterfall into their accounting system. They "Captialize"
>software as it moves through the various waterfall phases. This has
>a significant impact on their tax burden.
>
>Clearly they have to change their accounting model in order to move
>to iterative development. This is an astounding example of how
>interdependent things can become.
I'm not so sure that this is a problem. Bertrand Meyer advocates a "cascade"
lifecycle where you break up a project into clusters (Steve Mellor calls them
"domains"), each of which is small enough for two or three people to do in a
month or two. Then each of these clusters is developed in a mini-Waterfall.
The "requirements document" for each cluster is the interface it offers its
clients.
You could integrate this into the Waterfall Capitalisation accounting system
by declaring each cluster to be a mini-project, and assigning it a value.
Paul.
--
Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 473331 ext 2245+-----------+-----------------------------------------+
Work: <paul.j...@gmrc.gecm.com> | You are lost in a twisty maze of little
Home: <Pa...@treetop.demon.co.uk> | standards, all different.
Robert Cowham
rma...@rcm.oma.com (Robert C. Martin) wrote:
>
snip
>
>Iterative development, and quick-cycle hacking are two different things.
>In iterative development the iterations are on the order of a few weeks.
>Each iteration produces a more functional version of the product than
>that last. The iterations are *planned* ahead of time, and are even
>given tentative (and highly inaccurate) dates. As the iterations
>proceed, the schedule is updated. The time it took to actually complete
>an iteration is data that can be fed back into the schedule to help
>predict how long it will take to complete the other iterations.
>
Some RAD methods use the technique of timeboxing where the dates of iterations
are fixed, yet the content of iterations is not fixed - items can be slipped
to the next release. An example is DSDM (Dynamic Systems Development Method)
which is gaining a lot of acceptance here in the UK.
---------------------------------
Robert Cowham cow...@logica.com
Logica UK Ltd, 75 Hampstead Rd, London NW1 2PL, UK
Opinions expressed are my own
David Linthicum
as long as you build in OOA/OOD, it's going to take longer than using a
RAD development approach. The tradeoff is OO. Using RAD, developers are
quick to blow by a proper application design to obtain development speed,
however is they are using OO in a waterfall they are not.
This is driven by RAD tool vendors who are selling tools as "programming
without design." MIS management likes the idea of RAD, and therefore are
moving in that direction. It's cheaper, the clients like it, and seems
to provide an effective approach to development. The trouble comes in
when we think that we can actually build good OO software without
considering how to setup the objects. I see RAD application after RAD
application that are so much trash since the developer did not take the
time to build them right the first time.
My 2 cents
Ell
:...
: Agreed, this is not waterfall. Moreover, most of this is very
: traditional OO thinking. Our previous confusion was primarily due to
: vocabulary. You were contrasting Booch's vertical slices to your
: horizontal slices. But you don't really have horizontal slices (in
: terms of Analysis, Design, Implementation). YOu have orthogonal slices
: in terms of subject areas.
Couldn't it be true that an orthogonal slice is a horizontal layer with
its own layer analysis, design and implementation?
: My only comment here is that you still need vertical slices. It would
: be a grave flaw to analyse and develop the subject areas separately.
: There is no good way to keep them in sync except to cut vertical slices
: through the entire product, touching all the subject areas, and make
: those slices deliverables in a schedule. In that way, for each
: scheduled deliverable, the subject areas must be in sync. This closes
: the loop and staves off the integration nightmare.
While I think this is true, isn't it possible to develop parts of a system
relatively independently, at times, based on specification of the
interfaces between the parts? Which is another reason why establishing
"structural" architecture "early on" is often a good thing. The
interfaces between parts being determined of course by overall system
analysis and consequent overall system architecture.
Elliott
Robert C. Martin
rmartin said:
> My only comment here is that you still need vertical slices. It would
> be a grave flaw to analyse and develop the subject areas separately.
> There is no good way to keep them in sync except to cut vertical slices
> through the entire product, touching all the subject areas, and make
> those slices deliverables in a schedule. In that way, for each
> scheduled deliverable, the subject areas must be in sync. This closes
> the loop and staves off the integration nightmare.
>
I disagree entirely.
That surprises me. I thought we were coming to terms.
What do mean "to keep them in sync?"
Given any two domains that must work together in some project. If the
two domains are not tested against each other, then the designers will
have no reason to communicate. They will not prove that the services
of one domain satisfy the needs of the other. They will add services
that the other domain doesn't need, and they will not implement
services that the other domain does need. And none of this will be
discovered until final integration.
Consider an application domain that depends on an OODBMS domain.
Why is a grave flaw to build the OODBMS separately from the
application? Why will there be an integration nightmare?
Have you ever worked with an OODB that has never before been tied to
an application? I came close to this once. I was part of a project
which was one of the first users of a major OODB about 4 years ago.
The OODB designers had done a real nice job of designing what they
*thought* application designers would need. But they were wrong about
what we needed. The OODB had lots of bells and whistles that we just
didn't need, and was missing some fundemental features that were
extremely important. It was close to Hell.
That is the real issue. You can't design domains in isolation. You
can't build domains in isolation. Integration between the domains
should be frequent and scheduled.
William D. Gooch
>The issue is that when using the "traditional" waterfall methodologies,
>as long as you build in OOA/OOD, it's going to take longer than using a
>RAD development approach. The tradeoff is OO. Using RAD, developers are
>quick to blow by a proper application design to obtain development speed,
>however is they are using OO in a waterfall they are not.
Good, experienced developers are not prone to falling
into this trap. A lot of people these days seem to think
that the "right" methodology is a panacea. Problem is,
there is no "right" methodology (Alan Kay has said that
none of them are even close).
Some people will do well regardless of (or in spite of)
methodology, or the lack of one. On the other hand, some
people will do poorly regardless of methodology. The
methodology itself isn't a solution, it's merely a crutch.
Ell
: Some people will do well regardless of (or in spite of)
: people will do poorly regardless of methodology. The
: methodology itself isn't a solution, it's merely a crutch.
Granted methodolgies are not a solution, does that mean we can throw our
Rational Roses, Objectorys and OMT Tools away since they are only
crutches?
Elliott
William D. Gooch
>Granted methodolgies are not a solution, does that mean we can throw our
>Rational Roses, Objectorys and OMT Tools away since they are only
>crutches?
That depends mostly on who you are working for, and whether
you have the experience to work without a formal definition of
methodology to support you. Less formal methods, and com-
binations of aspects of different formal methodologies, can be
very effective if used well. Plain old seat-of-the-pants hacking
without a plan is fairly unlikely to take you to specific goals.
I have seen methodology lead off on tangents, and even away
from success on occasion, and I think it is best not to take the
formal methodologies too seriously. They can be very effective
if used well, but it is also possible to go through the complete
gamut of a methodology and still not understand what you are
trying to accomplish. Focussing too much on the details of the
methodology itself, rather than the application problem space,
causes this.
David Linthicum
>Good, experienced developers are not prone to falling
>into this trap. A lot of people these days seem to think
>that the "right" methodology is a panacea. Problem is,
>there is no "right" methodology (Alan Kay has said that
>none of them are even close).
I have to agree. However, there should be some sort of formal approach
to the problem. A methdology provides step-by-stop process of moving
through the problem. Good developers are not prone to falling into the
"prototyping death spiral," but I know a lot of programmer who are. :-)
You need some sort of approach, even if it's your own.
>
>Some people will do well regardless of (or in spite of)
>methodology, or the lack of one. On the other hand, some
>people will do poorly regardless of methodology. The
>methodology itself isn't a solution, it's merely a crutch.
So are you saying that we don't need a methology? Or, are you saying
that there is a tradeoff?
-- Dave Linthicum
Kent Beck
st...@projtech.com writes:
>Paul's text above is indeed how we view it: The first step in the
>Shlaer-Mellor method is to identify the layers, by identifying
>subject matters (we call them problem domains), and depicting
>the dependencies between the layers in a "domain chart".
>
>Then we analyze each domain (each layer) independently of one another.
>...
>I quote again the last three lines of the original post:
>> > ........... Most development organizations still prefer a
>> > pile-of-paper-based illusion of control to active management of
>> > development risk.
>
>
>1. Identifies the domains (layers) in the system, as the first step
>2. Immediately moves to understand (and document) the dependencies
> between the domains
>3. Analyzes each domain separately and (relatively) independently
>
>is taking on active management of development risk, through explicit
>management of the dependencies between the layers. Further, we
>begin this very early on in the development process. Finally I say
>for one last time, that such a process is not a waterfall.
>
The worst risks in the world are integration risks, because you can't
possibly find them until you see the whites of their eyes. If the
domains are all well understood, such risk is minimized because you
know where the landmines are buried. This is never the case for
interesting software. Most competitive software developers are forced
to innovate in several domains at once.
I recommend to my clients that they use practices that maximize
communication between developers of dependent layers-
shoulder-to-shoulder development, episodic design (Ward Cunningham's
phrase- see the Episode patterns in http://c2.com/ppr), group CRC
review, and Grady's vertical slice-o-functionality.
I agree with Robert Martin- integrate early, integrate often.
Kent
Matthew B. Kennel
: I would claim that most compaines are not getting the benefits promised by
: OO because they have chosen to use C++ rather than a true OO system
: (Smalltalk, Objective-C, to name a couple).
: I would claim that many companies are not getting the benefits promised
: by OO because they expect a 'true' OO system to provide those benefits
: automatically.
: Asserting that C++ is in any way responsible for people not achieving
: the benefits of OO is a silly as asserting that people aren't making
: money on the stock market because they are using the wrong broker.
This is not as silly as it seems; it's certainly the case that a broker with lousy
commissions (and worse) a big spread and bad execution can render profitable
strategies not so.
The broker could argue "Well it's not my fault that you aren't gaining the
benefits of good stock selection". This is superficially true, but misses
the overall point, which is to make profits and a bad broker is an
impediment to that.
Thus "the benefits of OO" is a means to easier and better programming and
everything about a language matters, not just its object-ness.
: The benfits of OO come from understanding and applying the principles of
: OOD. These principle lead, irrepective of OOPL, to programs that are
: more maintainable, more robust, and more reusable than those that do
: not. These benefits do not automatically come from any particular
: language. Not even Smalltalk.
By virtue of personal experience I think there are language features
often, but not always, distinct from "object orientation" that make the
programming process
"more maintainable, more robust, and more reusable"
If this were not so why even use C++? Because C++ 'supports' people
programming object oriented systems better than C or Fortran. I think there
are languages that do the same to C++.
: There is nothing about any of the C++ environments that I am aware of
: (and I am aware of a few) that prevent, interfere with, or even slightly
: impede iterative development.
I can think of one right away: the lack of static type inference, where the
declared types of variables can depend on the result of other expressions.
In a langauge which does do this (e.g. Eiffel & Sather for OO languages) you
can change return types and attribute types of one object or subroutines
under development and other dependent pieces of the system will often change
automagically to make things fit and simultaneously retain full static type
checking. It decreases the friction of change.
This is not a trivial benefit.
The lack of GC means that you have to build in logic and facilities for
various kinds of storage management too early in to your design. You end
up fixating upon some representation too early. GC decreases the
friction of changes.
I didn't appreciate either of these until I wrote programs in a langauge
which did them. I'd hate to go back.
: On the other hand, the C++ complile and
: link loop can be longer than the Smalltalk edit and go loop. So quick
: cycle hacking is easier in Smalltalk than in C++. (Unless you are using
: a tool like Object Center which allows quick cycle hacking in C++).
: --
William D. Gooch
>....
>You need some sort of approach, even if it's your own.
Sure, as long as we agree that "approach" need not mean
"formal methodology."
There are tradeoffs, and whether formal methodology is
needed depends on the circumstances. As you said, there
is always "some ... approach" which guides the process,
even if its an unplanned or poorly planned approach. Full
blown formal methodology is fine especially for large projects,
but tends to be too overhead-intensive for small ones.
Patrick D. Logan
>On the other hand, the C++ complile and
>link loop can be longer than the Smalltalk edit and go loop. So quick
>cycle hacking is easier in Smalltalk than in C++. (Unless you are using
>a tool like Object Center which allows quick cycle hacking in C++).
This is dangerously close to the complaint Robert had about B. Meyer's
recent book and Meyer's section about "C hackers". Martin's quote
above seems to imply that the Smalltalk language and environment, where
it differs from the C++ language and environments, only serves
hacking rather than controlled iteration.
Harumph. To each his own.
BTW I used Object Center two years ago. It is the right direction in
many ways for C++, but at that time was not well suited for developing
large applications. There were severl hoops to jump through and
limitations that prevented truly 100 percent quick cycle "hacking"
as Robert puts it.
Ell
Or at least much of it is unneeded for small, and or less complex
projects. Keeping "relative" conceptual distinctions between phases (and
this _does not include_ a temporal stepping between phases), and how
development is viewed in terms of developer vs. user needs is still of
importance for small, and or less complex projects, imo.
Elliott
tut...@velveeta.enet.dec.com
In <jzq...@bmtech.demon.co.uk> Scott Wheeler
<sco...@bmtech.demon.co.uk> writes:
>
>In Article <30AF37...@vmark.com> Jeff Sutherland writes:
>>... the Waterfall Methodology is fatally
>>flawed and doomed to failure....
>
>Is this news? I was under the impression that this had been generally
>accepted for at least 20 years.
>
>Scott
All of the writers in this thread seem to be arguing that the waterfall
method "is dead", and that the iterative method is superior for _any_
project using object technology. Is it not possible that methods
are like computer languages in that you must choose the one which best
matches the problem to be solved, and that no one method is _always_
preferred?
Some time ago I witnessed a project in which a team of 8 people was asked to
redesign an existing legagy system from scratch. Future versions of the
product would add further functionality, but the first phase would only
replace the current system. As such, the requirements were very well known.
The team attempted to develop the product using a spiral methodology, in
which they divided the project into slices, and then tried to develop each
slice using a mini waterfall.
The project was a failure. It was "delivered" 30% late with only 50% of the
functionality. They found that with each design-a-little, code-a-little,
test-a-little interation, that they did a substantial amount of redesign
and recoding of the code at the interfaces between the vertical slices.
They concluded that the total amount of work needed would have been
greatly reduced had they spent more time on the up front analysis and
design.
They took another crack at the system using a waterfall method. This time
they even took the waterfall to an extreme by staying in the design phase
(not creating a single line of code) until the product had been designed
down to the function call level throughout. This time the project
finished on time with a much lower level of defects than expected.
It seems to me that there are times when different methods are appropriate.
When requirements are very well known (as above), or if the level of complexity
of the problem is not very large (as in a college homework assignment), the
waterfall method may be more appropriate. Granted, these conditions do not
apply to many (if not most) of today's real world applications, but I don't
buy that the iterative design method is _always_ more appropriate where
object technology is used.
-- Tim Uttormark
tut...@velveeta.apdev.cs.mci.com
Bill Crews
William D. Gooch <goo...@rwi.com> wrote:
>In article <494h5n$f...@dub-news-svc-3.compuserve.com> David Linthicum <70742...@compuserve.com> writes:
>
>>The issue is that when using the "traditional" waterfall methodologies,
>>as long as you build in OOA/OOD, it's going to take longer than using a
>>RAD development approach. The tradeoff is OO. Using RAD, developers are
>>quick to blow by a proper application design to obtain development speed,
>>however is they are using OO in a waterfall they are not.
>
The entire raison d'etre for methodologies is to formalize what is otherwise
in someone's head so that it may be used by others, so that it may be
used to coordinate the work of many, and so that project results are more
predictable. Years ago, I found that I had a talent for RADing projects
-- that is, expediting projects and surviving with happy clients -- but I
have been struggling project by project since then to formalize how I do it.
Iteration/feedback is certainly an essential ingredient. I won't consider
a methodology without it built in. But vertical slices need _interaction_
or _interplay_, not iteration between them. With horizontal slices,
either interaction or iteration seems to work fine. Unfortunately, each
published OO methodology seems to omit something essential, so I am still
trying to roll my own. Hmmmm... Maybe it is getting to be time to write?
-bc
--
----------------------------------------------------
Bill Crews | cr...@panix.com | New York, NY, USA
Cathy Mancus
In article <49ffbj$o...@dns1.mci.com>, tut...@velveeta.enet.dec.com () writes:
> It seems to me that there are times when different methods are appropriate.
> When requirements are very well known (as above), or if the level of
> complexity of the problem is not very large (as in a college homework
> assignment), the waterfall method may be more appropriate.
I think you have put your finger on a very important, oft-overlooked
(at least by management) point, and it goes beyond the waterfall/iterative
battle. Specifically, the success of most projects depends on how
well the requirements are understood early in the design phase.
The biggest headaches on projects I've seen up close are almost never
due to "bad" design; they are due to design that didn't take into account
requirements that were "discovered" late in the design phase or even
the implementation phase. The same thing can happen in an interative
model, because it is not time- or resource-efficient to scrap half the
design in a late iteration and recode it all.
I believe the biggest weakness in the software business today is
the lack of sufficient process, and understanding of process, to figure out
what you want to build *before* you call in the programmers to design and
implement it. Even the best designers will often lack background in the
domain in which they are working, due to high turnover and large amounts
of contract work.
[The above opinions are my own; no corporate entity is responsible.]
/-------------------------------------------------------------------\
| Catherine Mancus <ca...@zorac.cary.nc.us> |
| PP-SEL, N5WVR "God is a sponge." |
\-------------------------------------------------------------------/