Waterfall VS XP
jabber
I am working on my term paper which will be a comparison between
waterfall and XP.
I searched the group, I know there are some similar topics posted
before, I read them all
but could not get enough information. I see that there are people in
the group who are very proffessional and have great experience in
Software Engineering. if you can please list
Strengths,
Weakness,
Opportunities,
Threats,
for WATERFALL and as well as for Extreme Programming I would appreciate
it.
Thanks
Erkan
Phlip
> I am working on my term paper which will be a comparison between
> waterfall and XP.
Read the book /Agile and Iterative Development: A Manager's Guide/ by Craig
Larman. It explains the repeated accident of history that is Waterfall, and
the various studies which show how incremental development works better.
One very influential finding: The more closely projects followed the strict
Waterfall model, the worse they tended to perform.
BTW your question is going to lead you to an incredible amount of garbage,
from both "sides", so good luck sorting it all out!
Until you get that book, Google for "DOD-STD-2167". You will find lots of
hits for DOD-STD-2167A, which is an edit on 2167 that rescinds the
requirement for strict waterfall. Lots of incredible history there...
--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
kk_...@yahoo.com
I think you should be comparing Waterfall to Iterative/Spiral
development. A good bokk that does that is Software Project
Management: A Unified Framework by Walker Royce. As to XP, it is one
of many iterative processes (one that I like a lot). However, there
are others that get used quite a bit out there in the real world, such
as RUP and SCRUM. The Larman book recommended by Philip describes each
of those.
Here's a short note to consider about waterfall vs iterative:
Waterfall is a workflow based on fallacy. It makes the assumption that
when you complete a "phase", such as requirements definition, design or
code, etc., you never look back or change what came prior. This never
has been a real workflow. Organizations who say they are waterfall
rarely are in practice. So it ends up these waterfall organizations
come up with all sorts of aritfacts, metrics and formal reviews to make
it seem like they are waterfall. Much time gets wasted doing such
activities.
One key bit of evidence that waterfall doesn't work is that
DOD-STD-2167 has been obsolete for a long time (I think as far back as
1997 or 1998--a google search should provide the actual date).
Mil-STD-498 replaced it to make it more spiral/iterative oriented--and
even that document has been made obsolete by IEEE documents that allow
for even more iterative approaches.
Good luck!
Ken
Isaac Gouy
1) Don't believe everything you read!
http://www.library.wisc.edu/instruction/believe.htm
2) Phlip recommended "Agile and Iterative Development: A Manager's
Guide"
Unhappily some of the "evidence" in that book does not match the
information given in the original studies - that problem was discussed
on this newsgroup January-March 2005.
3) afaict software development at DoD became increasingly legalistic as
vendors routinely went to court when they were not awarded a contract -
which made projects overdue before they'd even begun. iirc there was
something about that in Capers Jones "Software Assessments,
Benchmarks, and Best Practices".
Phlip
> Here's a short note to consider about waterfall vs iterative:
> Waterfall is a workflow based on fallacy. It makes the assumption that
> when you complete a "phase", such as requirements definition, design or
> code, etc., you never look back or change what came prior. This never
> has been a real workflow. Organizations who say they are waterfall
> rarely are in practice. So it ends up these waterfall organizations
> come up with all sorts of aritfacts, metrics and formal reviews to make
> it seem like they are waterfall. Much time gets wasted doing such
> activities.
Who cares?? If I want to bust on XP, I will write anything, including
screaming support for Waterfall on USENET!!!
;-)
slippymi...@yahoo.com
> Guide"
> Unhappily some of the "evidence" in that book does not match the
> information given in the original studies - that problem was discussed
> on this newsgroup January-March 2005.
Are there cites concerning the problems in that book in these previous
discussions? I was considering purchasing the book, should I
reconsider?
Phlip
>> 2) Phlip recommended "Agile and Iterative Development: A Manager's
>> Guide"
>> Unhappily some of the "evidence" in that book does not match the
>> information given in the original studies - that problem was discussed
>> on this newsgroup January-March 2005.
>
> Are there cites concerning the problems in that book in these previous
> discussions?
Google Isaac Gouy's name on USENET. He devoted considerable effort to
digging up all the citations and finding minor differences between their
conclusions and Larman's use of them.
Nobody else has bothered to perform this research or make any sites about
it.
> I was considering purchasing the book, should I
> reconsider?
It's a manager's guide to iterative development. All thought leaders
recommend iterative processes these days. And, yes, Waterfall is still out
there and still sucks. There's nothing morally or technically wrong with the
book.
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Isaac Gouy
> slippymississippi wrote:
>
> >> 2) Phlip recommended "Agile and Iterative Development: A Manager's
> >> Guide"
> >> Unhappily some of the "evidence" in that book does not match the
> >> information given in the original studies - that problem was discussed
> >> on this newsgroup January-March 2005.
> >
> > Are there cites concerning the problems in that book in these previous
> > discussions?
>
> Google Isaac Gouy's name on USENET.
That is a great way to find what I have written and a bad way to find
comments on "Agile and Iterative Development: A Manager's Guide"
From
http://groups.google.com/group/comp.software.extreme-programming/
put the full book title in the text field by the "Search this group"
button and search comp.software.extreme-programming for comments about
the book.
> He devoted considerable effort to digging up all the citations and finding minor
> differences between their conclusions and Larman's use of them.
>
> Nobody else has bothered to perform this research or make any sites about it.
At the time I found it quite shocking that people would actively
promote the book as providing evidence without bothering to look at the
original sources - but that was before "A Million Little Pieces", that
was before "truthiness".
Minor differences? I disagree and suggest that others read the original
sources and make their own judgement (online versions of some sources
were given in last years discussions.)
> > I was considering purchasing the book, should I
> > reconsider?
>
> It's a manager's guide to iterative development. All thought leaders
> recommend iterative processes these days. And, yes, Waterfall is still out
> there and still sucks. There's nothing morally or technically wrong with the
> book.
I wonder how you explain the differences between what the original
studies say and what "the book" claims they say?
Ron Jeffries
>I wonder how you explain the differences between what the original
>studies say and what "the book" claims they say?
They are differences of interpretation: what you say the originals say, and what
Larman says the originals say. Both interpretations are subject to error, yours
and his.
I know Larman and am confident that if there are significant differences between
what the originals say in some platonic ideal sense, and his interpretation,
that they are honest mistakes, not some kind of odd attempt to deceive, as your
writings seem often to be suggesting.
I would also say that the general flavor of the book reflects what I've
encountered visiting and advising many projects over the past decade. If the
book does have errors of detail -- and I'm not saying whether it has or hasn't
-- it is certainly true to the world as I encounter it.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Isaac Gouy
> On 26 Apr 2006 12:50:08 -0700, "Isaac Gouy" <ig...@yahoo.com> wrote:
>
> >I wonder how you explain the differences between what the original
> >studies say and what "the book" claims they say?
>
> They are differences of interpretation: what you say the originals say, and what
> Larman says the originals say. Both interpretations are subject to error, yours
> and his.
Mr Jeffries, iirc when you last commented on this subject, you had not
actually looked at the original source material - have you now looked
at the original source material?
Phlip
> Mr Jeffries, iirc when you last commented on this subject, you had not
> actually looked at the original source material - have you now looked
> at the original source material?
Ooh, that was almost a field goal, Mr. Jeffries. But I just moved the goal
posts another *20* miles from your current location. Care to try again?
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Ron Jeffries
>> They are differences of interpretation: what you say the originals say, and what
>> Larman says the originals say. Both interpretations are subject to error, yours
>> and his.
>
>Mr Jeffries, iirc when you last commented on this subject, you had not
>actually looked at the original source material - have you now looked
>at the original source material?
No, Mr Gouy. Are you wondering whether I'd agree with your interpretation or
his, or suggesting that it is somehow necessary to read source material in order
to conclude that if two people read some source material, and interpret it
differently, the differences are ones of interpretation?
I would be happy to look at one such piece of material and say whether my
interpretation is more like his, more like yours, or different. Is there
something on line that you'd suggest?
But my reading of the material, and yours, and Larman's, may all differ. That,
in itself, doesn't make any of us right, or wrong.
One other thing. I was thinking when I wrote my previous reply that it seemed
odd to me that you would apparently recommend in general that people should read
the source material, rather than books that are based on source material. Is
that your recommendation. Is that the case?
I ask in order to understand your position better, and to try to determine
whether you have a particular axe to grind with Larman and Agile, or whether you
are also all over other fora, inviting people to read the Bible in the original
Aramaic, and to check out what Galileo said in Latin before talking about
whether the earth goes around the sun.
Regards,
Isaac Gouy
> I would be happy to look at one such piece of material and say whether my
> interpretation is more like his, more like yours, or different. Is there
> something on line that you'd suggest?
>From "Agile and Iterative Development: A Managers Guide"
"Research shows that timeboxing itself brings benefits in terms of
increased productivity." page 54
"Timeboxing by itself has been shown to have a productivity effect.
DuPont, one of the earliest timebox pioneers, found developer
productivity around 80 function points per month with timeboxed
iterations, but only 15 to 25 function points for other methods.
[Martin91]" page 77
How should we interpret that - is "Agile and Iterative" providing the
DuPont data as evidence that "timeboxing by itself" improved developer
productivity?
"Agile and Iterative" cites James Martin, "Rapid Application
Development" 1991 as the source for the DuPont data - and there are
matching DuPont function point per month numbers on pages 224-225.
DuPont found that using timeboxing /and a CASE tool/ improved
productivity compared to using a traditional lifecycle and 3rd/4th
generation programming languages.
"Agile and Iterative" fails to mention that the higher productivity was
with a CASE tool and the lower productivity was with 3rd/4th generation
programming languages.
Without that information we have no reason to doubt that the DuPont
data is evidence that "timeboxing by itself" improved developer
productivity. With that information we know that the DuPont data is not
evidence of "timeboxing by itself".
(Last year I used the public library to get a copy of James Martin
"Rapid Application Development" 1991. Some of the material has been
copied online "Productivity with CASE" and "Wide Variations in
Productivity"
http://sysdev.ucdavis.edu/WEBADM/document/radmanage-studies.htm )
Isaac Gouy
-snip-
> One other thing. I was thinking when I wrote my previous reply that it seemed
> odd to me that you would apparently recommend in general that people should read
> the source material, rather than books that are based on source material. Is
> that your recommendation. Is that the case?
Where do you think I suggested that people read the source material
/rather/ than the books?
No and no.
> I ask in order to understand your position better, and to try to determine
> whether you have a particular axe to grind with Larman and Agile, or whether you
> are also all over other fora, inviting people to read the Bible in the original
> Aramaic, and to check out what Galileo said in Latin before talking about
> whether the earth goes around the sun.
iirc Last year Robert Martin and yourself referred me to chapter 6
Evidence in "Agile and Iterative" (in the same way that Phlip just
referred jabber to the "various studies" in "Agile and Iterative").
I thought some of the reported evidence was really interesting so I
looked at the original studies to find out more. I was unpleasantly
surprised by differences between the reported evidence in "Agile and
Iterative" and some of the original studies, and I was disappointed by
the weakness of some of the original studies.
kk_...@yahoo.com
<snip>
> iirc Last year Robert Martin and yourself referred me to chapter 6
> Evidence in "Agile and Iterative" (in the same way that Phlip just
> referred jabber to the "various studies" in "Agile and Iterative").
>
> I thought some of the reported evidence was really interesting so I
> looked at the original studies to find out more. I was unpleasantly
> surprised by differences between the reported evidence in "Agile and
> Iterative" and some of the original studies, and I was disappointed by
> the weakness of some of the original studies.
I'm confused about this whole thread. The original poster was asking
about the virtues of XP vs. Waterfall. I would venture to say that all
participants in this thread would agree that waterfall stinks, as
evidenced by the obsoleting of both 2167A and Mil-STD-498.
Also, anyone who has done programming or management of programmers in
real life knows that waterfall is a myth that never happens even when
companies say it does. The Walker Royce book talks clearly about
waterfall vs. spiral. The Larman book discusses alternatives to
waterfall, XP being one of them. If you want to know which alternative
works best for you, just pilot a few. You'll never know for sure until
you do, regardless of any case studies or original sources, etc. After
all, I'm sure a lot of talking heads did a lot of studies to show the
virtues of waterfall back in its day. I'm also sure that those talking
heads hadn't really done much programming in the real world (i.,e, they
probably did most of their work in academic environments).
Note that I am currently on a small team piloting XP to determine if it
should replace our 2167A waterfall approaches on a bigger scale. We've
also applied Scott Ambler's agile modeling ideas (see
www.agilemodeling.com). Now we're also experimenting with utilizing
Doxygen to satisfy some of our modeling artifact requirements. We're
not doing any of these things purely by the book. We're taking
ideas/techniques that seem to address problems we've directly
experienced over the past 20 years in the field and tailoring them to
meet our unique needs. So far, it's working out well. Perhaps that's
because it seems that all the "founders" of these methods come from the
hands on programming world, as opposed to the ivory tower of academia.
Whatever approach is used, I think the keys are to have:
- system engineers (ie, requirements specifiers) working closely with
software developers throughout the lifecycle
- Strong communication among the software developers
- repeatable, automatically executeable unit and integration tests
- functionality-based (as opposed to sloc based) progress tracking
- the ability to move fluidly between design and code.
Waterfall does not allow for any of this (at least that's my
experience). Just about any of the methods described in Larman's book
do.
See ya,
Ken
Phlip
> I'm confused about this whole thread. The original poster was asking
> about the virtues of XP vs. Waterfall. I would venture to say that all
> participants in this thread would agree that waterfall stinks, as
> evidenced by the obsoleting of both 2167A and Mil-STD-498.
Firstly, the spec 2167, without the A, required waterfall explicitely. Its
use was directly correlated with humongous failures. The bigger the project,
the higher the odds it would fail. These experiences lead to a large number
of studies which overwhelmingly identified waterfall as the common aspect of
all these failures.
The military system responded by taking waterfall out of 2167, producing
2167A. However, waterfall still emerged (see below), so the military wrote
498 to explicitly forbid waterfall. These transitions represented an entire
movement of theory and thought, for millions of programmers in thousands of
projects, and they are not some idle fiction of any individual book.
However, all new ideas attract detractors who like to brag that they are
smarter than the early adopters. Craig Larman could not have written a
useful book if he recited every finding of every study, so of course he
takes shortcuts. Waterfall still sucks.
> Also, anyone who has done programming or management of programmers in
> real life knows that waterfall is a myth that never happens even when
> companies say it does.
What typically happens is - regardless of the team's stated religion - they
start with Code-and-Fix. Then unexpected requirement changes cause huge
delays, and the bosses say, "okay, next time we will get all requirements
right, first. Then we will design them all together." I have heard with my
own ears managers in this situation say exactly that. Waterfall always has
been and always will be reinvented by ignorant managers burned by
Code-and-Fix.
> Whatever approach is used, I think the keys are to have:
>
> - system engineers (ie, requirements specifiers) working closely with
> software developers throughout the lifecycle
> - Strong communication among the software developers
> - repeatable, automatically executeable unit and integration tests
> - functionality-based (as opposed to sloc based) progress tracking
> - the ability to move fluidly between design and code.
>
> Waterfall does not allow for any of this (at least that's my
> experience). Just about any of the methods described in Larman's book
> do.
Props.
Isaac Gouy
> Isaac Gouy wrote:
> <snip>
>
> > iirc Last year Robert Martin and yourself referred me to chapter 6
> > Evidence in "Agile and Iterative" (in the same way that Phlip just
> > referred jabber to the "various studies" in "Agile and Iterative").
> >
> > I thought some of the reported evidence was really interesting so I
> > looked at the original studies to find out more. I was unpleasantly
> > surprised by differences between the reported evidence in "Agile and
> > Iterative" and some of the original studies, and I was disappointed by
> > the weakness of some of the original studies.
>
> I'm confused about this whole thread. The original poster was asking
> about the virtues of XP vs. Waterfall. I would venture to say that all
> participants in this thread would agree that waterfall stinks, as
> evidenced by the obsoleting of both 2167A and Mil-STD-498.
>
> Also, anyone who has done programming or management of programmers in
> real life knows that waterfall is a myth that never happens even when
> companies say it does.
XP 2004, Invited Talk, Ian Hugo
http://www.xp2004.de/xp2004/talks/ianhugo.pdf
'Let me give one example of the possible limitations of XP from the
late 1990s. British Telecom at the time was a fervent advocate of DSDM,
adopting it for most software development. One task it faced then was
the need for an additional digit in UK telephone numbers. That
requirement was simple to specify but entailed a great deal of effort,
since it involved every telephone exchange in the country and the
change rippled out extensively within existing software; so it was a
large project. However, the requirement was certainly not going to
change during the life of the project. In that case, British Telecom
decided from the outset on a traditional waterfall approach to the
project, which was successful.
In a sense, that example is trivial; I'm sure most of you could think
of an example in which XP might not be the best approach. My reason for
giving it is to counteract any "religious" fervour there might be
around. One of the biggest mistakes we have made in the short history
of IT is to attach a kind of religious fervour to new developments that
tends to elevate them to a panacea for all our ills.'
And a paper referenced by "Agile and Iterative" - although without
mention of this part of the conclusion :-)
"Product Development Practices That Work: How Internet Companies Build
Software" MIT Sloan Management Review 42(2) Winter 2001
http://www.sloanreview.mit.edu/smr/issue/2001/winter/6/
"In a world where customer needs and the underlying technologies in a
product are known with certainty, only one large microproject is
necessary, and the waterfall model suffices. An evolutionary-delivery
model represents a transcendent process for managing the development of
all types of software, with the details tailored to reflect each
project's unique challenges."
Isaac Gouy
> kk_oop wrote:
>
> > I'm confused about this whole thread. The original poster was asking
> > about the virtues of XP vs. Waterfall. I would venture to say that all
> > participants in this thread would agree that waterfall stinks, as
> > evidenced by the obsoleting of both 2167A and Mil-STD-498.
>
> Firstly, the spec 2167, without the A, required waterfall explicitely. Its
> use was directly correlated with humongous failures. The bigger the project,
> the higher the odds it would fail. These experiences lead to a large number
> of studies which overwhelmingly identified waterfall as the common aspect of
> all these failures.
>
> The military system responded by taking waterfall out of 2167, producing
> 2167A. However, waterfall still emerged (see below), so the military wrote
> 498 to explicitly forbid waterfall. These transitions represented an entire
> movement of theory and thought, for millions of programmers in thousands of
> projects, and they are not some idle fiction of any individual book.
>
> However, all new ideas attract detractors who like to brag that they are
> smarter than the early adopters. Craig Larman could not have written a
> useful book if he recited every finding of every study, so of course he
> takes shortcuts. Waterfall still sucks.
Let's nip that in the bud - there's no suggestion that "Agile and
Iterative" should recite "every finding of every study".
'The "fallacy of special pleading" is committed when we selectively
omit significant information because it would weigh against a position
we are promoting. The result of those omissions is a serious distortion
of the subject under discussion.'
When "Agile and Iterative" fails to mention that the higher
productivity was with a CASE tool and the lower productivity was with
3rd/4th generation programming languages it is a serious distortion.
Phlip
Isaac Gouy
Phlip wrote:
> kk_...@yahoo.com wrote:
>
> > I'm confused about this whole thread.
>
> Tell us when that gets better.
Perhaps that will be when Mr Jeffries has the opportunity to look at
the James Martin book.
Phlip
> Perhaps that will be when Mr Jeffries has the opportunity to look at
"We Tried Baseball and It Didn't Work"
http://www.xprogramming.com/xpmag/jatBaseball.htm
"The fanatical proponents of baseball tell us that it is a very exciting
game, fun to play and fun to watch. They are clearly either stupid or evil
or both, because we tried baseball and it didn't work.
"First of all, the requirements for the game are stupid: it does not scale.
They say you need at least nine players on a side. That's stupidly
inefficient. The minimum number of players is clearly four: three men on
and one batting. That's how we played: four people on a side..."
Dude, you are the first person I thought of when I started reading...
Isaac Gouy
Why? Chapter 6 of "Agile and Iterative" claims to be factual evidence
not fictional innuendo - "An allegory? Sarcasm? Humorous pastiche? You
decide."
Isaac Gouy
> On 26 Apr 2006 17:06:59 -0700, "Isaac Gouy" <ig...@yahoo.com> wrote:
>
> >> They are differences of interpretation: what you say the originals say, and what
> >> Larman says the originals say. Both interpretations are subject to error, yours
> >> and his.
> >
> >Mr Jeffries, iirc when you last commented on this subject, you had not
> >actually looked at the original source material - have you now looked
> >at the original source material?
>
> No, Mr Gouy. Are you wondering whether I'd agree with your interpretation or
> his, or suggesting that it is somehow necessary to read source material in order
> to conclude that if two people read some source material, and interpret it
> differently, the differences are ones of interpretation?
>
> I would be happy to look at one such piece of material and say whether my
> interpretation is more like his, more like yours, or different. Is there
> something on line that you'd suggest?
Mr Jeffries, have you managed to get hold of the material I suggested?
If you say which city you're located in I could try and check the
libraries for you - alternatively Amazon have copies for $1.94
http://www.amazon.com/gp/offer-listing/0023767758/ref=dp_olp_2/002-1803445-9052833?%5Fencoding=UTF8
Ron Jeffries
>Mr Jeffries, have you managed to get hold of the material I suggested?
>
>If you say which city you're located in I could try and check the
>libraries for you - alternatively Amazon have copies for $1.94
>
>http://www.amazon.com/gp/offer-listing/0023767758/ref=dp_olp_2/002-1803445-9052833?%5Fencoding=UTF8
Other things on my plate, Mr Gouy, plus since I don't foresee either of us
changing position, it has a low priority. I'm curious, but not much more than
that.
Ron Jeffries
>Mr Jeffries, have you managed to get hold of the material I suggested?
>
>If you say which city you're located in I could try and check the
>libraries for you - alternatively Amazon have copies for $1.94
>
>http://www.amazon.com/gp/offer-listing/0023767758/ref=dp_olp_2/002-1803445-9052833?%5Fencoding=UTF8
I clicked one up, though, since $1.94 is within my price range on this problem.
I wonder how so many vendors converge on $1.94 ...
Isaac Gouy
> On 14 May 2006 18:34:08 -0700, "Isaac Gouy" <ig...@yahoo.com> wrote:
>
> >Mr Jeffries, have you managed to get hold of the material I suggested?
> >
> >If you say which city you're located in I could try and check the
> >libraries for you - alternatively Amazon have copies for $1.94
> >
> >http://www.amazon.com/gp/offer-listing/0023767758/ref=dp_olp_2/002-1803445-9052833?%5Fencoding=UTF8
>
> Other things on my plate, Mr Gouy, plus since I don't foresee either of us
> changing position, it has a low priority. I'm curious, but not much more than
> that.
For simple curiousity the material reproduced online should be enough
http://sysdev.ucdavis.edu/WEBADM/document/radmanage-studies.htm
But when it's a matter of "what you [sic Mr Gouy] say the originals
say, and what Larman says the originals say" then you need to look at
the originals.
As to "either of use changing position" - for you, the original
material is new information; I have already seen that information.
Phlip
> But when it's a matter of "what you [sic Mr Gouy] say the originals
> say, and what Larman says the originals say" then you need to look at
> the originals.
Personal experiences tend to work best in these forums. What process do you
use? How has it worked?
(In all these years I don't think you told us...)
Isaac Gouy
Phlip wrote:
> Isaac Gouy wrote:
>
> > But when it's a matter of "what you [sic Mr Gouy] say the originals
> > say, and what Larman says the originals say" then you need to look at
> > the originals.
>
> Personal experiences tend to work best in these forums.
Previously Phlip spake thus "Read the book /Agile and Iterative
Development: A Manager's Guide/ by Craig Larman."
Phlip
>> Personal experiences tend to work best in these forums.
>
> Previously Phlip spake thus "Read the book /Agile and Iterative
> Development: A Manager's Guide/ by Craig Larman."
>
> What process do you
>> use? How has it worked?
So I don't keep what process I use a secret...
What book would you recommend? What book has influenced your process?
Isaac Gouy
Phlip wrote:
> Isaac Gouy wrote:
>
> >> Personal experiences tend to work best in these forums.
> >
> > Previously Phlip spake thus "Read the book /Agile and Iterative
> > Development: A Manager's Guide/ by Craig Larman."
> >
> > What process do you
> >> use? How has it worked?
>
> So I don't keep what process I use a secret...
>
> What book would you recommend? What book has influenced your process?
You do keep recommending this book "There's nothing morally or
technically wrong with the book."
Mr Jeffries has stated that so far he has not looked at the original
material referred to in the evidence chapter of "Agile and Iterative" -
have you looked at the original source material?
Phlip
> You do keep recommending this book "There's nothing morally or
> technically wrong with the book."
That's because I'm not shy about taking a technical stand.
You, however, have spent years pestering this newsgroup about XP, while
apparently keeping your own process rather quiet.
So what would you recommend?
Isaac Gouy
Phlip wrote:
> Isaac Gouy wrote:
>
> > You do keep recommending this book "There's nothing morally or
> > technically wrong with the book."
>
> That's because I'm not shy about taking a technical stand.
But apparently shy of saying whether your unqualified statement of
Agile and Iterative's perfection is based on knowledge or ignorance of
the original source material.
Phlip
> ...
This is just idle gain-saying.
Your position here is indistinguishable from a person who has never worked
in software engineering. Someone only capable of reading PDFs and parroting
back arguments.
If you indeed have experience with software engineering, then you could
compare it with our experience. This would be much more useful - to all of
us - than any book.
Isaac Gouy
> Isaac Gouy wrote:
>
> > ...
>
> This is just idle gain-saying.
>
> Your position here is indistinguishable from a person who has never worked
> in software engineering. Someone only capable of reading PDFs and parroting
> back arguments.
The skills required to check if the "evidence" in "Agile and Iterative"
matches the information given in the original studies are simple
clerical skills.
Have you made use of those simple clerical skills, have you looked at
the original source material?
(That isn't gainsaying - it's a question.)
Ron Jeffries
>> That's because I'm not shy about taking a technical stand.
>
>But apparently shy of saying whether your unqualified statement of
>Agile and Iterative's perfection is based on knowledge or ignorance of
>the original source material.
I'll let Phlip speak for himself. My statements are based on my personal
experience.
Ron Jeffries
>The skills required to check if the "evidence" in "Agile and Iterative"
>matches the information given in the original studies are simple
>clerical skills.
>
>Have you made use of those simple clerical skills, have you looked at
>the original source material?
>
>(That isn't gainsaying - it's a question.)
The real way to find out whether Agile and Iterative work is to try them.
Another way is to listen to those who actually do them. A rather poor way is to
read documents written years ago and try to ferret out information that might
bear on the subject.
A really poor way is to try to pick holes in the books written by people who
read documents written years ago and try to ferret out information that might
bear on the subject.
I've done it, for ten years. I've met with hundreds of people who do it. Teams I
work with find themselves doing better based on the advice I give them, which is
pretty much right off the Agile menu. That's not because I'm a wonderful
advice-giver, though in fact I like to think I'm pretty good at it. They prosper
because the ideas in Agile really work.
We can argue about whether some guy who isn't here made any mistakes in his
book, or we can talk about how to build better software. I'm inclined toward the
latter.
Ron Jeffries
>For simple curiousity the material reproduced online should be enough
>http://sysdev.ucdavis.edu/WEBADM/document/radmanage-studies.htm
>
>But when it's a matter of "what you [sic Mr Gouy] say the originals
>say, and what Larman says the originals say" then you need to look at
>the originals.
>
>As to "either of use changing position" - for you, the original
>material is new information; I have already seen that information.
I don't need new information about Agile, Isaac, I've been doing it for ten
years. The question was whether your interpretation of the doc, or Larman's, is
more nearly accurate. I'm mildly interested in that. Ordered the book, will look
at it.
Imagine for a moment that I completely agreed that your interpretation of
Martin's quote was right, and Larman's was wrong. (I do not so agree, having not
read the original yet.) But if I did agree ... then what?
David Wolff
Isaac Gouy <ig...@yahoo.com> wrote:
> Phlip wrote:
>> Isaac Gouy wrote:
>>
>>> ...
>>
>> This is just idle gain-saying.
>>
>> Your position here is indistinguishable from a person who has never worked
>> in software engineering. Someone only capable of reading PDFs and parroting
>> back arguments.
>
> The skills required to check if the "evidence" in "Agile and Iterative"
> matches the information given in the original studies are simple
> clerical skills.
>
> Have you made use of those simple clerical skills, have you looked at
> the original source material?
>
> (That isn't gainsaying - it's a question.)
Evasion noted.
This is not a tough question. That you refuse to answer it makes one
wonder why.
Thanks --
David
(Remove "xx" to reply.)
Phlip
> Evasion noted.
Thank you. I went on the attack after reading an obituary (actually a sigh
of relief) on the wonderfully balanced and healthy news:sci.math
"...he never put forward a standpoint of his own for
all the time I knew him in discussion groups.
"He criticized others, played verbal volley ball with people, referred
to what others had said, but I never ever heard him take a stand for
anything."
Isaac Gouy
Ron Jeffries wrote:
> On 15 May 2006 12:02:36 -0700, "Isaac Gouy" <ig...@yahoo.com> wrote:
>
> >For simple curiousity the material reproduced online should be enough
> >http://sysdev.ucdavis.edu/WEBADM/document/radmanage-studies.htm
> >
> >But when it's a matter of "what you [sic Mr Gouy] say the originals
> >say, and what Larman says the originals say" then you need to look at
> >the originals.
> >
> >As to "either of use changing position" - for you, the original
> >material is new information; I have already seen that information.
>
> I don't need new information about Agile, Isaac, I've been doing it for ten
> years. The question was whether your interpretation of the doc, or Larman's, is
> more nearly accurate. I'm mildly interested in that. Ordered the book, will look
> at it.
Where did I say that you needed new information about Agile, Ron?
For you, the original material is new information on the topic "what
you [sic Mr Gouy] say the originals say, and what Larman says the
originals say".
Isaac Gouy
Ron, you've stated repeatedly that you have no personal experience of
the original source material referenced in "Agile and Iterative".
Isaac Gouy
1) The question is a red herring which diverts discussion away from the
issue of whether 'some of the "evidence" in "Agile and Iterative" does
not match the information given in the original studies'.
2) Phlip stated "There's nothing morally or technically wrong with the
book." but won't say if he has looked at the original material referred
to in the evidence chapter of "Agile and Iterative".
Phlip referred to a specific "influential finding" from "Agile and
Iterative" - The more closely projects followed the strict Waterfall
model, the worse they tended to perform.
2a) The original material is available online (and has been discussed
before on this newsgroup)
http://www.softwaretechnews.com/stn5-4/benchmarking.html
(see page 9 and 10) Robert Solon Jr., and Joyce Stratz 2002,
"Benchmarking the ROI for Software Process Improvement (SPI)", Software
Tech News Volume 5, Number 4.
http://www.softwaretechnews.com/stn5-4/stn5-4.pdf
The original material lacks so much basic data that imo it's folly to
draw any conclusion - we don't know if the projects were comparable in
size, we don't know if the projects were comparable in quality, we
don't know if the projects used comparable technology, we don't know...
Maybe all the "prototype" projects were 2 day one-person throwaway
projects using Ruby and the "waterfall" projects were 6 month 15-person
deployed projects using COBOL - we just don't know.
2b) Some of the information given in "Agile and Iterative" page 76 does
not match the information given in the original material.
""A study [Solon02] against a sample set (43,700 projects) showed the
following productivity differences between IID and waterfall:
Rigorous IID or Evolutionary Prototyping: 570 FP
Rigorous Waterfall: 480 FP"
Those "productivity differences" are for an /unknown number/ of
projects - they are based on data from just 2 years out of 11 years of
data collection.
The original material makes no mention of "IID or Evolutionary
Prototyping" just /prototyping/ - these could be throwaway prototypes.
Phlip
> 1) The question is a red herring which diverts discussion away from the
> issue of whether 'some of the "evidence" in "Agile and Iterative" does
> not match the information given in the original studies'.
It most likely does.
> 2) Phlip stated "There's nothing morally or technically wrong with the
> book." but won't say if he has looked at the original material referred
> to in the evidence chapter of "Agile and Iterative".
>
> Phlip referred to a specific "influential finding" from "Agile and
> Iterative" - The more closely projects followed the strict Waterfall
> model, the worse they tended to perform.
Yes - I am distorting both my understanding of the book and its conclusions.
However, curiously enough, the few times I have experienced with Waterfall
projects, they had the exact problems the book ANECDOTALLY speaks of.
I think that's why nobody with experience seems to have the troubles with
the book that you claim to have. The book discusses study that _generally_
concur with their personal experiences.
Hence, maybe discussing real-life experience might be more productive.
> Maybe all the "prototype" projects were 2 day one-person throwaway
> projects using Ruby and the "waterfall" projects were 6 month 15-person
> deployed projects using COBOL - we just don't know.
Which side uses valid argument techniques now?
Isaac Gouy
Phlip wrote:
> Isaac Gouy wrote:
>
> > 1) The question is a red herring which diverts discussion away from the
> > issue of whether 'some of the "evidence" in "Agile and Iterative" does
> > not match the information given in the original studies'.
>
> It most likely does.
>
> > 2) Phlip stated "There's nothing morally or technically wrong with the
> > book." but won't say if he has looked at the original material referred
> > to in the evidence chapter of "Agile and Iterative".
> >
> > Phlip referred to a specific "influential finding" from "Agile and
> > Iterative" - The more closely projects followed the strict Waterfall
> > model, the worse they tended to perform.
>
> Yes - I am distorting both my understanding of the book and its conclusions.
>
> However, curiously enough, the few times I have experienced with Waterfall
> projects, they had the exact problems the book ANECDOTALLY speaks of.
>
> I think that's why nobody with experience seems to have the troubles with
> the book that you claim to have. The book discusses study that _generally_
> concur with their personal experiences.
"Agile and Iterative" does not have a chapter titled "Anecdotes" or
even an index entry "anecdotes". It does have a chapter titled
"Evidence" with a dozen index entries - that chapter cites /specific/
evidence.
In the case of [Solon02] "Agile and Interative" makes a straightforward
mistake about how many projects the "productivity differences"
comparison was based on; and alters the meaning of the original from
"prototyping" to "IID or Evolutionary Prototyping".
>
> Hence, maybe discussing real-life experience might be more productive.
>
> > Maybe all the "prototype" projects were 2 day one-person throwaway
> > projects using Ruby and the "waterfall" projects were 6 month 15-person
> > deployed projects using COBOL - we just don't know.
>
> Which side uses valid argument techniques now?
As I said "The original material lacks so much basic data that imo it's
folly to
draw any conclusion". Ruby vs COBOL is just weak reductio ad absurdum
to illustrate that point.
David Wolff
Isaac Gouy <ig...@yahoo.com> wrote:
>
> David Wolff wrote:
>> In article <1147744264.6...@i39g2000cwa.googlegroups.com>,
>> Isaac Gouy <ig...@yahoo.com> wrote:
>>> Phlip wrote:
>>>> Isaac Gouy wrote:
>>>>
>>>>> ...
>>>>
>>>> This is just idle gain-saying.
>>>>
>>>> Your position here is indistinguishable from a person who has never worked
>>>> in software engineering. Someone only capable of reading PDFs and parroting
>>>> back arguments.
>>>
>>> The skills required to check if the "evidence" in "Agile and Iterative"
>>> matches the information given in the original studies are simple
>>> clerical skills.
>>>
>>> Have you made use of those simple clerical skills, have you looked at
>>> the original source material?
>>>
>>> (That isn't gainsaying - it's a question.)
>>
>> Evasion noted.
>>
>> This is not a tough question. That you refuse to answer it makes one
>> wonder why.
>
> 1) The question is a red herring which diverts discussion away from the
> issue of whether 'some of the "evidence" in "Agile and Iterative" does
> not match the information given in the original studies'.
Red herring or not, it's a reasonable question. What's so hard about
answering it? Afraid of taking up bandwidth? This is Usenet, it's no
problem.
[48 lines of evasion snipped]
Phlip
> Isaac Gouy wrote:
>> 1) The question is a red herring which diverts discussion away from the
>> issue of whether 'some of the "evidence" in "Agile and Iterative" does
>> not match the information given in the original studies'.
>
> Red herring or not, it's a reasonable question. What's so hard about
> answering it? Afraid of taking up bandwidth? This is Usenet, it's no
> problem.
It's a red herring. Tell us what process you use now, and why you use it,
and what experiences you had with it and any other processes.
Or we consider you a troll who likes to play games here.
Isaac Gouy
It has no relevance to the issue of whether 'some of the "evidence" in
"Agile and Iterative" does not match the information given in the
original studies' - it's a red herring.
> Afraid of taking up bandwidth? This is Usenet, it's no problem.
> [48 lines of evasion snipped]
David, as you consider the content of "Agile and Iterative" and the
original material to be "lines of evasion" it seems you have no
interest in the issue I've been discussing.
Ron Jeffries
>Or we consider you a troll who likes to play games here.
Bottom line: DFTFT.
Isaac Gouy
And yet the "evidence" in "Agile and Iterative" continues to be given
unqualified recommendation as evidence for Agile.
If there are mistakes in "Agile and Iterative" should they be hidden or
should "Agile and Iterative" get the benefit of many people's
attention?
Ron Jeffries
>And yet the "evidence" in "Agile and Iterative" continues to be given
>unqualified recommendation as evidence for Agile.
>
>If there are mistakes in "Agile and Iterative" should they be hidden or
>should "Agile and Iterative" get the benefit of many people's
>attention?
Here's an idea. How about, as the Champion of Concern for Errors in "Agile and
Iterative", you prepare a web page containing, for each key item where you don't
agree with Larman's interpretation:
1. An appropriate-sized chunk of Larman's conclusion -- big enough to be clear
in context, small enough to be practical;
2. An appropriate-sized quote from the source document in question;
3. Your own comments regarding your presumably different interpretation of the
quote.
I'd be delighted to host the document on my web site, if you have no better
place to host it, or to point to it if you have somewhere to put it.
If you were to do that, you could make a real contribution rather than just
kvetching from the sidelines.
Regards,
Isaac Gouy
Here's an idea. You know the author, he's a friend.
Invite the author to clear up any specific misunderstandings that have
been brought to his attention. Invite the author to publish Errata for
"Agile and Iterative" on your website or his website.
As for your suggestion - we tried that on this newsgroup last spring.
It allows some folk to argue about "differences of interpretation: what
you [sic Mr Gouy] say the originals say, and what Larman says the
originals say" without actually looking at the originals to find out
what they say.
(afaict this is an example of Evasive Agnosticism - 'the attitude that
attempts to pass off vincible ignorance as if it were invincible. It is
one thing to say "I don't know" after long and assiduous research into
a subject. It is quite another to say "I don't know" when you haven't
even bothered to look into the matter. The person who succumbs to
evasive agnosticism uses ignorance as an excuse rather than a reason.')
As for making a real contribution - I provided the author with specific
feedback on these issues a year ago, and I've openly communicated these
issues in this forum.
I don't think feedback and communication are "kvetching" (I guess there
really was a need to add "Respect" as an XP value).
Phlip
> Bottom line: DFTFT.
Ooooh, not even with this?
"How to Fail with the Rational Unified Process"
http://www.agilealliance.org/articles/larmancraigkruchtenph/file
(Note one of the authors is Larman.)
"Step 1: Superimpose 'Waterfall' Thinking
Step 2: Apply the RUP as a Heavy, Predictive Process
Step 3: Avoid Object Technology Skills
Step 4: Undervalue Adaptive Iterative Development
Step 5: Avoid Mentors Who Understand Iterative Development
Step 6: Adopt the RUP in a Big Bang
Step 7: Take Advice from Misinformed Sources
"Conclusion:
We are confident that by following these seven steps, and applying the
checklist of misunderstandings, your adoption of the RUP and iterative
development will be a spectacular mess."
It has a long list of citations, and I'm just lying awake at night wondering
how many of them have been misinterpreted, but I'm certain I'l never know
because I just switched to a newsreader that literally has a "plonk"
button...
David Wolff
That's right. I'm interested in Phlip's simple question, which you have
now evaded for the third time.
Three strikes, you're <PLONK>ed.
Thanks --
David
Isaac Gouy
Ron Jeffries wrote:
> On 15 May 2006 12:02:36 -0700, "Isaac Gouy" <ig...@yahoo.com> wrote:
>
> >For simple curiousity the material reproduced online should be enough
> >http://sysdev.ucdavis.edu/WEBADM/document/radmanage-studies.htm
> >
> >But when it's a matter of "what you [sic Mr Gouy] say the originals
> >say, and what Larman says the originals say" then you need to look at
> >the originals.
> >
> >As to "either of use changing position" - for you, the original
> >material is new information; I have already seen that information.
>
> I don't need new information about Agile, Isaac, I've been doing it for ten
> years. The question was whether your interpretation of the doc, or Larman's, is
> more nearly accurate. I'm mildly interested in that. Ordered the book, will look
> at it.
If you are having trouble finding the DuPont information in "Rapid
Application Development" iirc it was on pages 224-225 in the edition I
checked.
Isaac Gouy
It's nearly 4 weeks since you ordered "Rapid Application Development",
have you not received it?
If you have received it then perhaps you could confirm:
1) that the graph shown on page 225 is accurately reproduced on this
webpage
http://sysdev.ucdavis.edu/WEBADM/document/radmanage-studies.htm
2) that "Agile and Iterative Development" fails to mention that the
higher productivity figures were for code generation using CASE tools
and the lower productivity figures were for programming with 3GLs and
4GLs - not for "Timeboxing by itself".
Ron Jeffries
>It's nearly 4 weeks since you ordered "Rapid Application Development",
>have you not received it?
>
>If you have received it then perhaps you could confirm:
>
>1) that the graph shown on page 225 is accurately reproduced on this
>webpage
>http://sysdev.ucdavis.edu/WEBADM/document/radmanage-studies.htm
>
>2) that "Agile and Iterative Development" fails to mention that the
>higher productivity figures were for code generation using CASE tools
>and the lower productivity figures were for programming with 3GLs and
>4GLs - not for "Timeboxing by itself".
I have it and will look at it when I have nothing more interesting to do. The
grass is growing very nicely lately, so it might be a while.
But suppose that what you say is true. Then what?
Isaac Gouy
How strange, to talk in hypotheticals when you have the evidence.
Let's follow the evidence.
Ron Jeffries
>How strange, to talk in hypotheticals when you have the evidence.
>Let's follow the evidence.
The evidence doesn't have anything to do with my question. My question is, what
are you going to do differently if I agree with your position on the quote, or
if I do not?
Isaac Gouy
Surely all that matters is the simple truth of what you see on the
pages of "Agile and Iterative" and James Martin's "Rapid Application
Development".
What are you concerned about?
Ron Jeffries
>> The evidence doesn't have anything to do with my question. My question is, what
>> are you going to do differently if I agree with your position on the quote, or
>> if I do not?>
>
>Surely all that matters is the simple truth of what you see on the
>pages of "Agile and Iterative" and James Martin's "Rapid Application
>Development".
Surely more things than that matter. In fact, that comparison doesn't matter
much to me at all, since I actually do and teach Agile and I know from
experience and observation how it works.
>
>What are you concerned about?
When I choose how to spend my time, I like to think in terms of what will happen
if I use my time in some given way.
If nothing is going to change, no matter what I find in those two books, then
there is no point doing it.
Therefore, I ask again: what are you going to do differently if I agree, or if I
Isaac Gouy
I've emailed the suggested xhtml page, for you to host on your website.