Comment by jnurmine | Hacker News Reader

Comment by jnurmine | Hacker News Reader

Parent Full thread

Software development perspective here, from the receiving end of project management.

In my experience, waterfall needs unlimited time and money. Waterfall fails hard when money or time are limited, in which case the likely outcome is that the head of waterfall will be massive and the tail will be rushed, so that one gets a design-heavy and rushed implementation with little or no testing and scant documentation etc.

A timeboxed waterfall with inflexible sculpted-in-stone time schedules are a recipe for burning in the ensuing deathmarch. The planning either cannot or will not anticipate all unknowns and/or the buffers dampening the impact of the unknowns shrink because of outside pressure. (What do you mean 8 months to make this thing, can't you do it in 2 weeks, haggle haggle, sold for 2 months; available time reduced by a factor of 4)

In contrast, (a theoretically ideal) agile or some other iterative method works fine if time or money are limited. The iterative nature allows for a cut-off after a sprint. Pull the plug and have a result of state-of-the-art at that point; of course the result then might not quite reach the viable dimension of MVP nor even resemble a product.

The Zen of waterfall:

At some level everything is waterfall. If anything is to get done at all, at some point the programmer has to make a plan, then put his head down, arse up and implement it.

At another level nothing is waterfall. If the plan is successful it was shipped to the consumer (which may be the programmer himself), and it's very presence changes things for the consumer in ways that they didn't foresee. They then realise they need a new set of changes.

What we call waterfall model is really referring to the scale. If the plan is grand, the specifications for such a grand plan need to be detailed, the implementation long, and the time between putting the head down and evaluating results is large, and we call it waterfall.

But if the stragegy is to explore the solution organically, the re-evaluations are frequent, the waterfall periods are short and we call the strategy something else.

So in the end everything uses waterfall. The programmer would not get the long periods of intense focus he need to be productive without it. But also nothing is waterfall, because no plan can foresee everything, it must be continually re-evaluated in the light of unexpected changes it brings as it is implemented.

I once ran a 45 person dev organization that used waterfall to ship a half dozen commercial applications a year, including dozens of localized and enhancement versions, and never missed a ship date over five years. And won numerous industry awards.

It can be done with waterfall.

Thats impressive, was it your shop?

I built the process. Or should I say, we built the process to best meet the specific requirements for our products and customers, as communicated by our product marketing team.

Our main strength was actually our Product Management director. He was excellent at collecting and communicating highest priority customer requirements. He was always questioning and pushing, and helping my engineers come up with better approaches and implementations.

He was also excellent at building external relationships do we had really good partnerships, and training/leading team PMs so they were good team leaders. He was so damn good at it they eventually he moved in from our little company to run all mobile for a $100B+ company.

This raises several questions:

1. How experienced were these people in the particular problem domain?

2. How long was a single development effort and how many people?

3. What do you consider Waterfall? Are we talking "pure" Waterfall where everything is truly done in set phases? Or do you have feedback loops in place, like testing integrated properly into the development phase?

4. What was the relationships like with customers? Was it one (or a small number) of consistent customers or a diverse set of customers (closer to contract/bespoke software work)?

1) Pretty young work force, we essentially trained everyone who came in.

2) typical team was 2-3 devs, 1-2 QA, project manager, product manager. Typical dev time was 6-9 months.

3) Waterfall has a pretty amorphous definition, our implementation not very pure, which is probably why it succeeded. Each component of a new release would start testing as soon as engineers had something testable. When all components passed QA we’d go into alpha, then beta.

4) It was consumer software, specifically targeted to graphics professionals on Mac/Windows. We had hundreds of thousands of customers, and delivered physically in floppies and CD Rom.

Reply on news.ycombinator.com