> > To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi.
Huh? Did you get the year wrong, or was he referring to a brand-new / not yet released / tool as a "standard" for some segment of his audience? AFAICR, Delphi was introduced in 1995, or at the very earliest, late 1994. Feels weird that he should mention it in a book published in 1994.
Of course the shortcomings of this model have been known for a long time to anyone building software and so a number of other models appeared.
From what I can tell, that assertion is common in Agile advocacy.
But from my experience as a professional software developer in the 1990s, and from reading stories about software development, waterfall was not used at Apple, Be, Commodore, Data General, Infocom, Microsoft, VisiCorp, and more.
That's not to say no one used a (modified) waterfall model. Simply that I haven't found evidence that it's meaningful to say it was the standard development model. [1]
[1] Technically, DOD-STD-2167A's apparent bias towards waterfall was a "standard", but I don't think that's what most people mean in this context, and in any case it was replaced by MIL-STD-498 in 1994, well before the Agile Manifesto.
I don't see much value in debating this. It seems clear to me that the people who wrote the Agile manifesto have experience in working in such, or similar environment and reacted to change it. And clearly that way of working was widespread enough and enough of a pain point to strike a cord. Certainly, when I first read the manifesto it struck a cord and I understood exactly where they were coming from. I think it is spot on.
What raises my hackles is the lack of any qualifiers, given how rarely it's used in the projects I know about.
Here's the introduction of Steve McConnell's "Rapid Development" from 1994 - well before the Agile Manifesto! - Chapter 1, page 1:
> The product manager told me he wanted to build a product right for a change. He wanted to pay attention to quality, prevent feature creep, control the schedule, and have a predictable ship date.
> When the time came to actually do the project, it became clear tha getting the product to market quickly was the only real priority. Usability? We don't have time. Performance? It can wait. Maintainability? Next project. Testing? Our users want the product now. Just get it out the door.
> This particular product manager wasn't the manager on just one product. He could have been almost any product manager I've worked for. This pattern is repeated day after day, state by state, all across the country. ...
This is as far from building a bridge as you can get. The next page of the book starts:
> [1.1] What is Rapid Development?
> To some people, rapid development consists of the application of a single pet tool or method. To the hacker, rapid development is coding for 36 hours at a stretch. To the information engineer, it's RAD - a combination of CASE tools, intensive user involvement, and tight timeboxes. To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi. To the manager desperate to shorten a schedule, it's whatever practice was highlighted in the most recent issue of Business Week.
Agile drew from earlier methods ("intensive user involvement", "rapid prototyping") which were pretty common even before Agile.