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.
In reply to Re^5: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by mr_mischief
in thread "Bah! Scrumbug!" (Lessons from the scrap-bin)
by locked_user sundialsvc4
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |