What can programmers learn from the construction industry? [closed]

Question

When talking with colleagues about software design and development principles, I've noticed one of the most common sources for analogies is the construction industry. We build software and we consider the design and structure to be the architecture.

One of the best ways to learn (or teach) are through analyzing analogies - what other analogies can be drawn from construction? (whether already in common use in software or not).

Please provide a description, or your personal experience, regarding how the programming concept is similar to the construction concept.

^{[Credit to Programming concepts taken from the arts and humanities for the idea]}

Answer 1

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?.

Answer 2

We have taken a lot of words and ideas from construction industry throughout the history of software development, and in fact we probably took to many, and I don't think there is anything left to take.

We took the whole process of having customers making a specification, then an architect planning, then engineers designing and lastly code monkeys implementing from the construction industry, and it turned out to be wholly misguided.

This is because when you build a house, if your foundation is wrong, you are effed. Seriously effed. To lift a building and replace it's foundations costs more than scrapping the whole thing and starting over. But in software it's completely possible. I've remade a client software into a client-server solution without the user noticing anything, except that I moved the modem to the server room. That's like replacing the concrete foundation with a boat while the inhabitants were sleeping.

Software is not like construction. And that's why the whole software industry turned on a time in the beginning of the naughties and the whole "waterfall" process of running projects was replaced with agile processes in just a couple of years.

As for words much is taken from construction, rightly and wrongly.

Framework is the most obvious one not taken already. And there are pipes.

Answer 3

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).

Answer 4

The terms Finish work and Trim come to mind.

The idea that it is ok to deffer some aesthetic choices for when the major structural decisions are complete.

Answer 5

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.

Answer 6

Limitations exist both in construction and programming.

If you as a customer can't make such ridiculous demands as to extend a finished hotel building over a weekend and put an airport into the underground floor and a runway on its penthouse, why can't you accept that not all adjustment with the finished software are possible? It's not a magic ball of 0s and 1s, it's a complex construction structure, though immaterial but with its limitations too.

Answer 7

I worked in construction through school and there are places where it's not even analogies, the same concept applies. But often, the comparison temptation goes way too far.

When I worked on an estimate for a job, I knew there were pretty firm averages on how long it would take to do something. For fabricating storefront windows for example, we simply counted the number of joints in the frames from the plans and had a pretty good idea how long that would take. Just like programming, we had to account for variables in schedule though that could suck the life out of you. For example: having a plumbing crew show up to find that the parking lot is being paved and they can't get into the building because of the hot asphalt in the way is rather expensive.

However, construction has thousands of years of experience to draw on. The fundamental rules of the trade are driven by the same laws of physics that they have always been. Wind load and dead load calculations are the same as they were when they were being done with slide rules. Improvements in tools and techniques have come along, but at a glacial pace compared to what we experience.

On the other hand, we are still discovering that many of our patterns and practices need room for improvement. Singleton used to be a good idea, now most who think about it prefer IoC/DI patterns.

Where we're also lacking is in meaningful licensing and certification. In many areas, even to just be a repairman let alone an installer, a plumber must be licensed or work under the supervision of someone who is. To get that license requires a certain amount of time working in field. I'm not making the case for or against licensing, just pointing it out as it is a huge difference.

Of course in both fields, an architect can draw something that can't be implemented.

Answer 8

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.

Answer 9

I know some construction companies that farm work out to the lowest bidder, do sloppy work, shirk what should be warranty duty, focus on date over quality, and then charge a ridiculous profit for the "finished" product.

But I don't think programmers or consulting agencies have learned anything from those practices.

Answer 10

Bugs can end up being expensive as hell, or even killing people?

Answer 11

There are basic guidelines for complex engineering projects of any discipline:

1. importance of planning, blue-prints, design, etc.,
2. importance of the underlying mathematics
3. reusing ideas/learning from other similar projects
4. using ready-made building blocks/components built by someone else
5. correcting problems very early in the life cycle
   etc.,

The commonalities between architecture, civil and software engineering disciplines seem to mainly stem from the absence of assembly lines: every project is unique in its own accord.

Answer 12

Overtime

But in the construction industry, workers get their overtime paid.

Answer 13

Use of standards, conventions, and pre-built components. You aren't likely to run into this kind of problem.

I can't find anything in the market that fits our custom built sockets.

Answer 14

When all you've got is a hammer, everything looks like a nail. :)

Answer 15

Repetitive strain injuries

They're an occupational hazard in both industries, and precautions must be taken to prevent them. Once they start, they're difficult to cure.