Post #243,902
2/8/06 6:42:04 PM
|
Call me a cynic
I still say the only advantage of waterfall is that you can get away with cheaper programmers because the whole thing is designed up front. (Yes, I'm ignoring the fact that anything you save on programmers you'll have to put into designers and architects to produce the spec, but I digress.) Once you've decided to get the cheapest programmers you can get away with, offshoring is the logical next step.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #243,903
2/8/06 6:42:36 PM
|
"Okay, you're a cynic." There, now no one else has to do it.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #243,916
2/8/06 8:48:50 PM
|
No, I'll just call you wrong. :-P
There are a lot of advantages of waterfall. Here are some:
- Many kinds of software (eg shrinkwrap) have very large deployment costs. That makes iterative development not really an option.
- Waterfall makes sense if you are contracting out a project on a fixed bid price. To protect the two sides the contract has to specify what will be built before anything is built to such an extent that you're basically going to be doing waterfall anyways.
- If you know what you want to develop, it is generally cheaper to develop it with a waterfall methodology.
In short, iterative development methodologies are not a pancea. They deserve a (fairly large) place in software development, but are not always appropriate. In any case I think you misunderstand the progression at this company. The company always used a waterfall methodology. However until a few years ago they weren't very strict about it, people would realize that they wanted tweaks to specs, would informally communicate them, and would generally be accomodated. However the phenomena of mutating specs came to be seen as a problem, and so a corporate policy came down of having a strict waterfall - in order to change a spec you absolutely had to have a formal change request which had to get formally reviewed, etc. In other words it wasn't mandating the waterfall methodology from scratch. It was a PHB saying, "Change requests are a problem, we have to limit them." And then limiting them by forcing them to go through bureaucracy. However once that was done it was certainly easier to make the second PHB choice of offshoring... Cheers, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #243,994
2/9/06 9:30:56 AM
|
Okay, my statement was too broad
I thought we were talking about internal IT working on internal products. In those cases I think iterative development is far better in nearly every case. For packaged software you obviously need something else. But even in an environment where deployment costs are high you can do an iterative development model. Do iterative development onto a test platform, when it's "ready" you deploy it. The real difference is how far in advance of the release you have to announce the final spec, and how you define "ready".
The one case where I wouldn't really question waterfall is a case where there is no internal IT, and the staffing will be put together on a per-project basis.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #244,172
2/10/06 5:10:23 PM
|
Re: No, I'll just call you wrong. :-P
Ben: There are a lot of advantages of waterfall. Here are some:
I'm going to gently disagree that the following are generally true :)
* Many kinds of software (eg shrinkwrap) have very large deployment costs. That makes iterative development not really an option.
Iterative development can still happen within a larger release deployment cycle. Just because its shrinkwrap, doesn't mean it needs to be waterfall.
* Waterfall makes sense if you are contracting out a project on a fixed bid price. To protect the two sides the contract has to specify what will be built before anything is built to such an extent that you're basically going to be doing waterfall anyways.
Fixed bid has the effect of inflated prices (the contracter is protecting his risk) and inflated requirements (because the customer is doing the same). It generally guarantees that both parties lose (late software for the client, penalty payments for the contractor) when the waterfall estimate is wrong (and you know it always is).
* If you know what you want to develop, it is generally cheaper to develop it with a waterfall methodology.
If you know what you want, and you have absoluting critical needs of getting exactly what you want (generally high risk software, e.g. the space shuttle), then waterfall might get you there, but I doubt it will ever be cheaper.
I'm not saything there isn't a place for waterfall, but the above reasons alone are not sufficient in my view to prefer waterfall over an agile approach.
--
-- Jim Weirich jim@weirichhouse.org [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #244,400
2/13/06 1:36:39 PM
|
We're mostly in agreement.
I think of most of the modified waterfalls as still waterfall. I think that the strict waterfall is stupid.
I agree on the problems with fixed bid contracts. But people still use them, and if I had to manage a project that was contracted out on that basis, I'd want to use a variation of the waterfall.
I agree that strict waterfall is only cheaper when the planets align and everything goes your way. But I believe that modified waterfalls can easily save over agile methods. It isn't a guarantee though. A competent agile team will beat an average waterfall team every time. Conversely a competent waterfall team will beat an average agile team every time. The interesting case is a competent waterfall team versus a competent agile team. There I believe it is a question of what your project looks like.
Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #244,406
2/13/06 2:01:31 PM
|
That can't be true
A competent agile team will beat an average waterfall team every time. Conversely a competent waterfall team will beat an average agile team every time. That's the same as saying the people are more important than the process. Don't you understand that the whole point of process is to make the people interchangeable? ===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #244,410
2/13/06 2:05:36 PM
|
PHB meets reality. Reality ignores PHB.
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #244,412
2/13/06 2:27:36 PM
2/13/06 2:30:10 PM
|
Damnfrigafraggamumblesputtercheckboxesfrigafraggamumble!
jb4
"Every Repbulican who wants to defend Bush on [the expansion of Presidential powers], should be forced to say, 'I wouldn't hesitate to see President Hillary Rodham Clinton have the same authority'."
&mdash an unidentified letter writer to Newsweek on the expansion of executive powers under the Bush administration
Edited by jb4
Feb. 13, 2006, 02:30:10 PM EST
|
Post #244,414
2/13/06 2:28:49 PM
|
ICLRPD (new thread)
Created as new thread #244413 titled [link|/forums/render/content/show?contentid=244413|ICLRPD]
jb4
"Every Repbulican who wants to defend Bush on [the expansion of Presidential powers], should be forced to say, 'I wouldn't hesitate to see President Hillary Rodham Clinton have the same authority'."
&mdash an unidentified letter writer to Newsweek on the expansion of executive powers under the Bush administration
|
