What's wrong with the analogy between software and building construction?

Question

Many people like to think of building software as constructing a building so we have terms like building blocks and architecture. However, lately I've been to a couple of talks and most people say this analogy is wrong especially around the idea of having a non-coding software architect in a project.

In my experience, good software architects are those who also write code so they won't design things that only looks good on paper. I've worked with several Architecture Astronauts, who have either limited or outdated experience in programming. These architecture astronauts quite often missed out critical details in their design and cause more harm than good in a project.

This makes me wonder what are the differences between constructing a software and a building? How come in the building industry they can have architects who probably never build a house in their life and purely handles design work but not in the software development field?

Answer 1

There are well-understood, well-defined ways of constructing a building so that it is safe for people to use or inhabit. A person who designs a house can be reasonably sure the builder will know what the blueprints mean.

No such generally-accepted blueprints exist for programming. Everything can be done multiple ways, with different methods and ideology.

Answer 2

Coding is more like artisanship- not quite art, still somewhat similar to construction.

Answer 3

In construction, the role of the architect is fairly different from the typical architect in software development. In construction, an architect performs tasks such as creating blueprints (similar to our specifications). I would say a construction "architect" is more similar to an experienced business analyst in software development. A good BA can create functional specifications without having coded themselves.

Additionally, in software development, the "architect" is generally expected to be a technical leader. In my opinion, a software development architect would be more analogous to the (lead) "builder" in construction. And, to become a builder, you must go through a very rigid process, working your way up from a basic apprenticeship, acquiring many skills over a lengthy period of time. This is also what we should expect of a software architect.

Answer 4

I have two observations when it comes to this

1. In contract to construction programming is also a design activity and the distinction between an architect and a programmer is extremely fuzzy. There are no construction workers who simply realize the plan. Final assembly of the ultimate design document, source code, is handled by a machine (more precisely a compiler or an interpreter).

2. In construction the cost of change is prohibitive and you rarely can afford to improve or modify what has already been built. On the other hand in software development the cost of change is minimal and refactoring is a common and recommended practice.

Answer 5

If a building crashes to the ground, it's a Very Bad Thing. You better get it right the first time.

By contrast, with software, it is much easier to experiment. If something works, great, if it doesn't, you have lost a little time, but learned something, and you didn't waste any (expensive) materials or kill anyone. Simulating and testing software is much easier.

It is common practice in software development (I think Joel and Jeff even discussed this in one of their podcasts, though their comparison was to surgery) to throw some code together, then do some debugging to find all of the bugs.

And the barriers to entry (for software programming) are pretty close to 0.

Answer 6

Architect's clients aren't allowed to demand that the building fly.

They can't take delivery of your finished underground carpark and ask you to add an airport (also underground)

They aren't allowed to change the law of gravity after you finish the design. Or expect the building to work on another planet.

They don't blame the architect when they can't get an 18 wheeler delivery truck through reception, into the elevator and to the loading dock that they demanded be on the 24th floor.

(Bitter, twisted, cynical - me ?)

Answer 7

Writing software is more like - writing.

The building and manufacturing analogies leave me cold. I think they're wrong at best, harmful and misleading at worst.

Answer 8

In addition to the answers by Matthew Jones and Chris Melinn, I would add that there usually exists many more layers of refinement and specialization between the tradtional architect and contractor as opposed to a software architect and the programmers. Architects provide the basic design and layout of a building, which on its own is far from the necessary amount of information needed to construct the building. That's why, before construction begins, you have others such as civil engineers, material engineers, building code analysts and others who take the conceptual design provided by the architect and create very detailed plans (describing the construction materials, structural beams, plumbing/electrical work, etc) which can then be given to the builder in order to begin construction.

This differs from software architects, usually because there exists no intermediary levels of specialization between the design and the code. That very conceptual idea which the software architect designs is usually given directly to the programmers to implement -- which can be very painful and time consuming, depending on how abstract the original plan is. It's analogous to having a traditional architect gave his design straight to the builder on site; he'd have almost no idea how to begin the project. The reason why software development differs from construction in this way is because it is usually cost inefficient to have the same multiple refining layers (it would be like having a software architect come up with a conceptual design, then having someone refine the design by listing the return types of all the functions, then having someone else refine the design by listing the parameters of all the fuctions, and then sending the detailed design to the programmer to commit to code -- those extra layers just aren't necessary, most of the time).

It's also important to note that traditional architects also suffer from the limitations of having no practical construction skills, as their designs are often unviable and need to be reworked before construction occurs -- just as programmers often have to change a software architect's design for practical concerns. So to say that architects can design buildings even without practical experience is only because they have a multitude of engineers and experts working beneath them who fix design issues before a shovel hits the ground.

Answer 9

There are building Architecture Astronauts as well. MIT's Green Building was designed by I.M. Pei to be impressive and on stilts, but the entrance doors were almost impossible to open because of the wind until wind shields were added. Most of Frank Lloyd Wright's buildings leak, and some of them have ridiculously pointy corners everywhere (30-degree angles) and ridiculously narrow corridors.

The book How Buildings Learn: What Happens After They're Built raises a lot of similarities with software development beyond the obvious. (Some excellent notes on the book)

Answer 10

I was considering this question just recently, in response to reading an article that compared software construction to bridge construction. The main problem with such a comparison is the fundamental difference in objectives between bridges and software.

Bridges are designed to allow a very limited subset of vehicles, adhering to a very limited subset of rules, to traverse from a very limited subset of origins to a very limited subset of destinations. As such, the requirements for individual components of bridge construction are rather trivial. Once such requirements have been defined, choosing the materials and construction methodology is almost a mechanical process.

Compare this with software design. Requirements are complicated, diverse, and change often. They are rarely fully understood. The degree to which requirements interact with each other grow exponentially according to the number of requirements. This same complexity does not exist in bridge construction.

The set of requirements must be deconstructed into a resulting set of software components. This deconstruction process relies largely on logical approaches to problem-solving executed by the software construction team, with difficulty that may be compared to performing mathematical proofs.

Introducing changes into a software project effectively increases the complexity of the software construction process. These increases in complexity are rarely afforded the necessary impact, as would be expected of bridge construction. You'll never hear a development leader say, "To change that major requirement will change the whole foundation of the project, so we'll need to extend the schedule by five years!"

Answer 11

Everything!

Creating software is more like making a movie than it is like constructing a building.

Construction has tangible outcomes and time-proven and tested techniques.

Software construction has been around 50 years compared to 5000 (approx.) years of building physical structures.

And as others have pointed out the consequences of failure might be more disasterous than just a disgruntled client.

Answer 12

I think we have more than enough ways to accurately blueprint software designs. Software can be designed correctly if its really needed. Check out this article about the software engineers who write the code for space shuttles: http://www.fastcompany.com/magazine/06/writestuff.html . A 420,000 line program with one bug? That sounds fairly well architected to me.

It just comes down to money. Imagine asking a team of builders to construct the Eiffel Tower in four weeks with $1000 of building materials. Then halfway through tell them that the tower has to be twice as high as originally specified and there MUST NOT be any further delay. The result would be exactly the same as many corporate software projects.

So what we are misssing is a cheap and fast way to make reliable software. The above article argues that we are in the hunter-gatherer phase of software development. That implies at some stage we will progress to a more civilised phase. I'm not sure I agree with that. Software is really complex, its going to get more complex as we see 8/16/32 core processors, and most people are not prepared to pay for really thorough software development.

Answer 13

Generally speaking a building just sits there. Although frankly that's all some software does, too.

Answer 14

Why coding is not like building a bridge

A modern computer and software suite is by far the most technically complex edifice ever constructed - far more complex than any mechanical or civil engineering project. Thus, a software project is an inherently complex task being undertaken in an environment where the interactions are far more complex and poorly understood.

Civil and mechanical engineering also take place in environments that are subject to well understood physical laws. Assumptions about the underlying behaviour of the environment of a non-trivial software project are much less robust and predictable.

Building a bridge is a fairly predictable exercise and can usually be completely specified up front before construction begins. Interactions with the environment are much simpler for a bridge than for a non-trivial software application. Thus, the specification and design process is fairly predictable - so predictable that incidents like the Tacoma Narrows Bridge are highly newsworthy events.

The relative level of detail that it is practical to specify software in is much further apart from the actual implementation than for a bridge and the environmental interactions are much more complex and much harder to evaluate up front. This means that there is much more uncertainty in coding as the design work is still underway while you are coding. Thus, coding is much less predictable.

Software projects tend to differ from each other much more than construction projects do. As the saying goes, the devil is in the details, much more so than on a construction project. Coding is more like artisanship than construction because the coder is making design decisions and applying creative problem solving as they work. Design problems on construction projects tend to bear much greater similarity to design issues on other construction projects and small details tend to have far less influence on the overall project than on software. Even the smallest detail can completely derail a software project.

A better analogy - building in the middle of a minefield from plans sketched on a paper napkin

Thus, by and large there are far fewer significant design decisions on a construction project and they have typically been investigated and solved up front. This means that programming is not really like building a bridge. A better analogy is building a bridge where:

• The client does not know where the bridge is meant to go. Requirements are almost never complete or accurate up front.

• The plans are sketched on the back of a paper napkin. Completely specifying a project to exact detail essentially implies building it to test the specification. Thus, the relative level of detail of software specs to the actual complexity of the implementation is much further apart than on a consturction project.

• Laws of physics may change in the middle of the project. Underlying assumptions about the environment may not be true. The environment is often not completely documented so the interactions between the project and the things it interfaces to are usually not fully understood up front.

• Finance does not believe your estimates and authorises half of the proposed budget. Budget estimates are often treated as the start of a negotiation process by sponsors. Computers don't negotiate - they either work or don't. Building robust, high quality software is time consuming, expensive and requires expert labour. Most people can't afford to do it.

• Materials are not subject to QA and may have critical structural flaws. Tooling and libraries may have bugs that cause problems in implementation.

• The construction site is situated in the middle of an invisible minefield. External influences and political issues can cause serious or critical damage to a project. Often, these cannot be predicted or effectively neutralised up front.

Answer 15

Looking at it from a different angle:

A building architect with actual experience with the nitty gritty of building will probably create better buildings. There are plenty of examples of this, for one Rem Koolhaas creates beautiful buildings but as a dwelling they suck as he invents stuff that just is not practically possible.

However, a lot of this is mitigated due to the relatively slow development within architecture. Keeping up and learning from others mistakes is therefor much easier to do.

For Software Architects the changes come much faster, so there is a strong need to get their hands dirty as they can not rely upon new techniques to come to them naturally over the years.

But the age old argument still holds: "We have been building homes for millenia, we have been building software for only a few decades."

We as a community are still learning...

Answer 16

I think it's simplistic to say that building architects have no hands on experience.

Yes, probably they haven't placed I-Beams or welded, but this is more analogous of the labor the computer processor does for programmers than the technical artistry. Much of the actual 'building' is labor intensive rather than craft work.

Properly laying out a building so there are enough bathrooms, light and so that it doesn't fall down....that's for the architect. That experience comes from a knowledge of the physical rules/laws to engineering, goals of the design and artistry.

Custom tiling for the lobby or woodwork paneling in an office are the craft work stuff. This lends itself to building out the components laid out by an architect. A good architect will build the structure, to make clear where each office wall ends, providing enough room, structure and facilities for the craftspeople (programmers) to do their work.

And, you are so very right about the dangers of a code-less software architect, or one too absorbed in the abstract -- distant from reality. Nothing....nothing at all....can make a project more expensive.

Answer 17

In a building, a poorly tightened nut on the cold water faucet of the third floor bathroom isn't likely to cause the basement furnace to explode, at least not as the first noticable symptom.

In most physical objects, the effect of one small mistake is going to be limited to things pretty close to that mistake. If you discover a problem, whether during design, construction, or later on in a maintenance phase, the root cause is probably going to be pretty close to where you found the symptom.

In software, while some bugs may have local effects, and good software engineering practices tend to decrease the chances of a small error having disasterous consequences far from the source, we can all tell stories of strange bugs where a small oversight in one place had disasterous consequences in a seemingly distant part of the code.

Answer 18

Here is a machine analogy:

In contrast to software projects, traditional engineering relies on tried-and-true materials and methods, applied in well-understood ways to new applications. An aeronautical engineer may design a new aircraft that does not look or function exactly like any previous plane, but the structural members, outer skin, wiring components, and engines usually are copies of proven parts and techniques. Manufacturing plants, skyscrapers, roads, and bridges are built with a similar philosophy -- substantial reuse of known pieces, put together largely in known ways.

Traditional engineers, of course, sometimes advance the state of their art, by using new materials or techniques or both. The Burj Khalifa recently set a new height record for buildings. The engineers did this partly by employing a special formulation of concrete to achieve the weight-bearing strength required, and by pouring the concrete at night to aid in proper hardening. But these innovations are in tightly constrained situations, making incremental improvements to well-studied topics. Concrete has been around for thousands of years in some format and 200+ years in its modern version. New bridges similarly use known methods, with possibly some incremental innovations to solve special problems for that location. The public would not have it any other way.

Software projects often take the opposite approach, attempting to use many radical new materials (data structures) operated on by grossly unproven methods (programming code) to produce a machine that performs a never-before-seen function. Our large software projects often resemble precisely the sort of absurd dream invention described above. Why do we do this? The reason is that since we cannot see or touch software, it appears that all the parts of software, tested or novel, are quite similar and can be used equally well as machine subassemblies. In fact, software components do not all have the same approximate reliability, not by a long shot. We fail to appreciate fully that well-tested software modules can have a high probability of successful reuse, while novel software components are often a crap-shoot.