To put it back in the analogy, building materials cost only a penny, and the builders themselves work for free. If the building falls over, you can rebuild it again and again at little to no cost.

The architects on the other hand, account for almost all the cost and time.

Which means that it is cheaper to quickly sketch the design freehand, and have the builders make a skyscraper based on the partial design every two minutes to observe how it falls down. Ten scrap buildings are cheaper than an hour of the architect's time. No sense wasting that time measuring, carefully drawing angles and lines and then inspecting the blueprints to be sure that the load bearing walls are actually attached to something. If it falls down, no harm is done and the sketch can be touched up a bit there. If it doesn't fall down, then everything is good and the sketching continues.

Rather than exotic metals, consider what things would be like if the shop were making water fountain sculptures. There would be no harm in running water through those fountains while they're being shaped and aligned. Each piece is not only allowed to, but actually encouraged to vary from the others like it. Cheap materials are flagrantly wasted, but expensive time is saved

Of course, it all starts to break down once the system becomes complex enough that it simply can't be done with sketches, eyeballs, estimations and hand-waving. After that fuzzy point of crossover, it becomes more expensive to sketch roughly and rework than it would have been to plan accurately from the beginning. Unfortunately, it seems to me that that point is also well on its way to complexity so high that it can't really be designed accurately, like a city rather than a building.

That high level of complexity is where standards come into play. You can recreate the whole thing several times for a small, isolated project. You might do a house, a subdivision, or even a small village as a planned community.

Yet when you get to things like cities, nobody implements the whole thing as one team. You have a zoning plan enforced by one group, a street plan sometimes enforced even separately from the zoning plan, there are building code requirements for all buildings in the city (with certain waivers and exceptions being made by application and consideration), permits must be issued for certain kinds of work, and some of the people involved in certain types of sub-projects must be licensed in certain jurisdictions.

There's an electric utility, a water utility, a sewer utility, a gas utility, a cable company, a land-line phone company, a cell company, an Internet access company, a trash service, a recycling service, and maybe a heating oil, LNG, or LP company. Some of those might be part of the city government. Some might be combined to provide more than one utility from the same company. In some cases their may even be some competition within the same city.

I'm not sure waterfall was all wrong. It certainly wasn't all right, but I'm not sure it was all wrong. Maybe sometimes the general plan should be handed down from senior staff to separate teams. Those separate teams might work better bottom-up on their part of the project. It's often important, though, for the data interchange among the different teams to be standardized.

One mess I've often seen is that one part of an application handles the same data along completely different lines from the rest of the program. Encapsulation being good, that's not a problem internally. Externally, though, where it interfaces with other parts of the program, having a duplicate and wildly different API or data format is just a silly requirement for one team to impose on the others. Standardizing what data formats each piece of the project will accept makes much more sense if all pieces are being written from the start. Leave the munging and glue code to tying different projects together.

Another place large projects sometimes really suffer from a lack of standardization across the project is in end-user interfaces. Features can get duplicated. Similar features can have surprising differences in their behavior. Sometimes different parts of the program even accept input in a different way than the user has come to expect from using the rest of the program. There's no need for any of that. You can develop a part for a larger whole in a different fashion under a different methodology and still put together pieces that fit in the larger project.

I think the biggest failings of Waterfall and of Structured Programming are in thinking that you can drill down exact specifications arbitrarily far. I think, likewise, that the failings of bottom-up methods like some agile methods and some lean methods try to be are in thinking you can implement and revise all the way up.

I think if you're working on a large enough project, then sometimes it's good to have a set of rules to implement toward from above when you're working up from below.

I'm not sure waterfall was all wrong. It certainly wasn't all right, but I'm not sure it was all wrong.

Dr. Royce was certain it wasn't all right.

I'm not sure waterfall was all wrong. It certainly wasn't all right, but I'm not sure it was all wrong.

I don't think it's a matter of right or wrong. It's important to recognize which method (be it waterfall, agile, something else) is suitable for which company/organization/project. What I do not is wrong is take an example of a production process which allows to partial redoing of the produce, and use that to show agile methods don't work on the design and implementation of a single product.

I think the biggest failings of Waterfall and of Structured Programming are in thinking that you can drill down exact specifications arbitrarily far.

I fail to see what "Structured Progamming" has to do with any of this. "Structured Programming" (that is, using blocks with single entry and exit points), is neither required nor prohibited by either Waterfall (or similar techniques) nor by any Agile method.

I think if you're working on a large enough project, then sometimes it's good to have a set of rules to implement toward from above when you're working up from below.

Scrum, or any agile method, does not mean big projects cannot be worked on (usually, big projects are collections of features), or that teams are kept in the dark of the big project their sprint is contributing to.