That is where design patterns came from.

The person that allegedly introduced the concept to the world was Christopher Alexander in his book "A Pattern Language: Towns, Buildings, Construction" in 1977. From there, the Gang of Four (GoF) picked it up, and the rest is history.

Even now during lectures and in software development and architecture books analogies between the construction world and the software development world keep prevailing.

Some analogies and references I can think of or recall:

• For example, changing requirements during the construction of a building it would perhaps become more evident to the client how absurd this is, e.g.: "OH, and I want a garage instead of where the kitchen you just finished is".
• Temporary aids such as scaffolding (meaning in construction world|software development)
• Clients cannot keep adding features without it costing them, lots of times they want stuff done for free, and sometimes we are dumb enough to accept; that just couldn't happen in the construction world (see requirements creep).
• The roles in software development: the architect is central to the design of the solution; consultor and contractor can be interchangeable terms; the workers are the programmers.
• The client cannot provide accurate requirements in both cases.
• Budgets and time estimates are often wrong.
• The product cannot be really seen in its true form until the end.
• A building might have construction faults after built, the same way software has bugs.
• If the product is badly done, sometimes it is preferrable to demolish and start over than fixing it.
• Not knowing about the actual and real outcomes of poor quality work, the client wants the cheapest solution.
• Open Source. I was just watching this talk from Doc Searls called "Why All Business Will Be Based on Open Source" where he tells how the construction community shares techniques and general knowledge instead of patenting them much like the open source community, even when some stuff in buildings contain proprietary products built-in.
• Projects turn out better for everyone if the client is involved actively.

(If more come to mind, I'll add them.)

There are some who don't think the general analogy is correct, a recommended reading for this is The Software Construction Analogy is Broken. Also, there is a question about this on SO titled What's wrong with the analogy between software and building construction?.

I've used this analogy... a lot of software projects start because the person who needs some software knows the equivalent of a "handyman", and they hire this person to build them the software equivalent of a garden shed. It's a small, useful little application that does its job very well.

The customer then goes back to the handyman, happy with their work, and asks them to change the software to do one more thing. A lot of times, this new feature doesn't have much to do with the original request, so it's almost like they're asking you to build another room on the back of the garden shed with a separate entrance.

Then they want to put a light inside the shed, so they have the handyman back, and he runs a single circuit from the main panel in the house, installs a pull chain light switch in the ceiling of each room and connects them to the circuit.

The customer then decides they want to run some power tools, but it keeps blowing the circuit breaker, so they call the person back and he actually has to rip out the single circuit he ran to the main panel, and install a larger conductor and a sub-panel in the shed. He had to run the wire twice, and pay for two electrical permits, etc. This is inefficient.

Then the client asks for something absurd: can you turn my garden shed into a garage? I don't want you to re-do anything you've done... I just want you to make it bigger so I can park my car in there. Then, in a lot of cases, the handyman thinks "the customer is always right" and proceeds to build additions onto 3 sides of the shed to make it bigger, knocks down the wall between the partitions, etc. Of course, the roof ends up sagging because it isn't constructed right, etc.

So the client isn't that impressed anymore, but they still want more. They ask the handyman back over and over to just add one more room, or change this existing room to do this, etc. You end up with something that looks like The Burrow and is about as architecturally sound.

Now most people aren't silly enough to try this in the construction world, but it happens all the time in the software world, because people don't make these connections:

1. A person qualified to build a really nice garden shed is not necessarily qualified to build a house.

2. If you knew ahead of time that you were going to build a house in stages, but it was only going to start as a garden shed, you'd do things differently and the garden shed would cost a lot more (you'd pour a really thick pad, make sure you ran a conductor big enough for the full load of a finished house, etc.).

3. In a lot of cases, upgrading from one stage to another involves undoing a lot of the work that was previously done, making it more expensive than it seems like it should be.

4. In the world of construction, we can give the customer a good idea what the result will look like during the design stage, but we don't have that ability in the software world. If you got it to that point, you've basically written a significant portion of the software.

The Agile Manifesto is a result of acknowledging that the software/construction analogy is broken. Things like automated unit tests and iterative release cycles have no parallel in construction. These things take advantage of the near zero cost of going from design to prototype (we call it compiling or building).

An old adage: Measure twice and cut once.

Edit: There is a section in The Checklist Manifesto by Atul Gawande, that talks about managing large construction jobs. When they get to a point that is really complicated, they have a meeting with the experts involved to revisit the problem and see if anything during the project has occurred that everyone should know about. We probably can't plan them as far in advance.

Scaffolding, "a temporary structure used to support people and material in the construction or repair of buildings and other large structures." ^{[definition from wikipedia]}

This concept works because a scaffolding in programming is able to be rapidly created and provides temporary functionality until the real structure is in place.