A discussion in DesignBeforeCoding included the remark "I'd hate to drive over a bridge that was designed during construction!". But coding is quite unlike CivilEngineering. All coding is design work on some level - the old idea that we can completely design our projects up front and then mindlessly code them according to the design is a long discredited bit of DisciplineEnvy. See also TheSourceCodeIsTheDesign, DesignIsNotaDevelopmentPhase -- PaulCrowley

The "up front" idea is so old I've never really seen it. It's just the monster in the closet. And other professions do not do complete design up front. On any building the architecture plans are still abstract. There is a lot of tactical discretion about how everything gets done and there is a lot of room for changes.

''On the other hand, everyone understands that making a bridge wider or longer will cost more, and take more time. This is seldom (in my experience) found in the design of software. -- PeteHardie''

I believe the bridge analogy is quite fair; the point of the analogy is that it you are a lot more likely to build a bridge correctly if you've designed it first. Simply because it is possible to stop in the middle of coding something and completely redesign and start over (which isn't a good idea when you are building bridge), does not mean it is something you want to do very often, and it certainly doesn't mean the time/effort you've spent up until now costed any less (proportionate to your project's budget) than the imaginary clueless bridge laborers' did. -- Patrick

http://www.newbaybridge.org/media/opt1lg.gif
http://www.newbaybridge.org/media/opt3lg.gif
http://www.newbaybridge.org/media/opt6lg.gif

''For an example of redesigning a bridge while building it, see http://www.newbaybridge.org/redesign/index.html - or alternatively, google for "bay-bridge fiasco"'' Actually a choice between alternative designs, 15% of the entire causeway project, due to appropriation constraints.

Can we consider such great works as the statue of David and the paintings in the Sistine Chapel in the Vatican as examples? Can one say that ThereIsNoConstructionPhase in these works? Was there no up front design employed? Were there not penciled in lines and models employed? Were there not scaffolds constructed and stairs and ladders used to "construct" the final work? Whether one considers programming an art or a science, one cannot avoid the partitioning of its coming into being (creation) as employing envisioning and realizing. Envisioning is planning and design. Realizing is production and demonstration. These are clearly analogous to phases of design and construction. To say ThereIsNoConstructionPhase and that one moves directly into producing and demonstrating without a clearly separate and distinct envisioning is difficult to understand. -- DonaldNoyes

I think you may be missing the point of the title of this page. All software development is "envisioning". "Realizing" is automatically done by the compiler. I spend most of the day planning software. My compilers construct it according to my plans.

''It is clear now what it is you mean by envisioning and realizing. You have used the word "construct" but it is evidently not a "phase", even though it is distinct and separate from your "planning" and is then actuated by an agent which includes the capability of converting plans into realizations. It seems strangely similar to a General Contractor converting a blueprint into a real thing.''

Except that real construction contractors are rarely given blueprints that would actually produce functional structures. Most have learned how to fill in the gaps that architects ignore. 

''Which makes a point. The blueprints issued for the construction of chemical plant, or a power plant, or a high-rise apartment complex are extensive and detailed. They are essential to the '''''production of functional structures'''''. They furnish the answers to the what, where, when and how, but still require the aid and support of the on-site architect (engineers/designers), and the contracting firms supervisors. Complex structures and non-trivial software processes are rarely completed without some input from the engineers/designers/supervisors during the ''''''construction phase''''''. This is somewhat equivalent to turning on "debugging" during compilation, making the designer/programmer available to correct "oversights". ''

I think the analogy broke down long ago. In software, we have the luxury of building the final product and destroying it thousands of times a day. We can easily automate its use. We have to be much more specific in our designs than architects do, but our designs are much cheaper to validate.

And also to cancel, when it is seen that they do not fulfill the necessary requisites for ongoing distribution, utilization and usefulness while at the same time, satisfying the goldOwners. Bridges are built because they are needed and have a long lifetime of usefulness and are eventually worth the investment. Software is often built to satisfy a different set of concerns, and when done in a profitCenteredEnterprise it is often difficult for decisionMakers to see futureEffects because of shortBenefitAndProfitHorizons.
-- DonaldNoyes