I've often taken exception to the common metaphor of software as a construction project, but i'm realizing that the use of this metaphor suffers as much from an inapt analogy as it does to an idealization of how construction projects develop.

[The architect] assured me that i really did need to plan everything in advance, otherwise i'd be subject to onerous change fees. He assured me that any contractor would take advantage of any changes of mind that i had as a way to boost his profits.

I've changed my mind plenty of times, and it hasn't cost me a cent. My contractor assumes that changes will be made. He wanted to make a building that i was happy with and that looked good and would sometimes suggest changes himself.

Actually, i have been charged one change fee. I moved the bath room after the plans had been drafted and my architect charged me to redraft them.

To paraphrase Albin, if designing, constructing, and maintaining buildings was like software development, building architects would be getting requests to have entire floors removed or added and additional structures appended onto the building.

The sidebar went on to note that urban engineering might be a better metaphor for software development, where engineers and planners receive requests for new housing developments, reducing traffic congestion, and connecting adjacent communities. Like any metaphor, Albin notes, this one also has limitations, but it certainly feels more applicable to me.

Every now and then I hear someone compare software development to bridge building. ... the implication is clear: bridge building is predictable, rote, unexciting, very manageable work, and software development is not. The only difference is whether the speaker likes software development the way it is, or wishes it could be different.

I think both positions are misinformed. ... In my experience, software developers tend to have an idealized, unrealistic view of what "real engineering" is like.