Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

The Software Construction Analogy is Broken

By mberteig in Technology
Fri Mar 14, 2003 at 09:47:03 AM EST
Tags: Software (all tags)

There is a compelling analogy between building and software construction. It is not new, but it has never taken root and bloomed... (http://www.wwisa.org/wwisamain/phil.htm)

The Problems with Software

Everyone who deals with software knows there is something wrong. Software is riddled with bugs, software is hard to use, and software development projects are frequently over budget, slip schedules, and sacrifice function and quality. In order to find solutions to these problems, software is often likened to construction. Unfortunately this analogy is flawed and lessons learned from the construction industry are suspect.

Many intelligent people have examined the problems with software and tried to find ways to fix them. Over the few decades that we have been writing software we have improved in many ways: our hardware is unimaginably capable compared to that of even one decade ago, our programming languages are easier to learn and offer far more features every year, our software development tools care for more complexity with every version. In some ways we have even made software that is easier to use. Nevertheless, the problems remain.

The Construction Analogy

Software would be much better for everyone if these problems were solved. Improving the development process is believed to be the key to solving these problems. Professionals working in the software development field often think "wouldn't it be nice if the process of building software was like the process of constructing a building?" We could be software architects and designers who conceive of the structure of the software. We could be software project managers who control software projects. We could be software engineers and developers (construction workers) who actually figure out the details and build the software. And finally, we could be software inspectors who verify the quality and standards of a software product.

This analogy is attractive because the beneficial effects of the construction industry are ubiquitous and integral to our lives. We live in houses and we work in commercial or industrial buildings. We see the amazing edifices such as the Egyptian pyramids, the European cathedrals, or the Petronas Towers. We all imagine that the construction industry, having grown out of millennia of practice, has much wisdom and advice to offer.

If only we could copy the construction industry with its architecture, project management, design, engineering, tools, rules, guidelines, and even its pre-fabricated parts. If we could do all this, so it is asserted, then we could solve all the problems we have with software.

Those who look to the construction analogy believe the following things can be learned and applied to software creation:

  1. The Architect is the creative center of the endeavor.
  2. The design of a system is finished before construction begins.
  3. The people doing the actual construction work can be treated as interchangeable human resources.
  4. The flow of information can be made one-way from client to architect to builder.
  5. The construction work can be completed and the result handed off to the client.

Over the next several paragraphs we will examine how the analogy is broken (disfunctional) and why it is dangerous to use the analogy to guide our efforts to make software better.

Distribution of Buildings... Isn't

A building is constructed in the place it will be used. Duplication of buildings is a major effort. Buildings are not distributed from a construction location to the place or places where they will be used. In fact, a building is considered exceptionally well designed if it aesthetically fits with its environment. On the other hand, software is almost always created in a different physical location (a development workstation) than the place it will be used or deployed. Software must be distributed (if it is commercial software such as an office suite or computer game) or deployed (if it is enterprise software). Unlike buildings, software is considered well designed if it can be made to work with little effort on many different hardware platforms in many different environments.

This difference has very significant consequences for the process used in construction versus what might be used in software. The construction industry has no advice to offer to the software industry about distribution questions. In fact the processes and techniques used by construction are heavily influenced by the requirement to build in place - to make it right the first time.

This difference also has economic factors. The physical manifestation of software is incredibly inexpensive compared to the cost of creating the definition of the software. Of course in construction, the physical cost (property and materials) can be a very substantial portion of the total cost of a building. The construction industry has no advice to offer on this economic difference.

Finally, this difference has an artistic component. Practitioners of building architecture are inspired to reach a completely different aesthetic goal than practitioners of software creation. The construction industry cannot help the software industry make beautiful software.

Public vs. Published Interfaces

In software, published interfaces (interfaces used by parties outside of the development team) are the most stable aspect of software. Nevertheless, published interfaces are only a specification and the actual implementation of an interface can change radically. For example, a communication interface specification such as TCP/IP can be implemented over many different physical layers: ethernet, 802.11b wireless, or even SneakerNet. The choice of implementation can be changed throughout the lifetime of a software system. Not only that, but it really is possible to change even a published interface. Can the analogous changes be made in a physical building? Are the requirements the interface? For example, square footage in a building.

"Project Management" is the Process for Construction

In a construction project there is one shot at making an essentially immutable physical structure. This immutability (which we will discuss more in the section "Buildings are Completely Rigid") is the central motivator for the process used by the construction industry. The only process or methodology that makes sense for building construction is the "waterfall": conceptualize, architect, engineer, construct, finish and hand over - period. It is true that these phases overlap, and that certain construction projects will emphasize different phases, but the essential process is just as immutable as the final product. This waterfall methodology more commonly goes by the name "project management." The Project Management Institute (http://www.pmi.org/) and other authorities on project management claim to be generic authorities, but in reality, they all have their roots deep in the construction and engineering disciplines. Software project management therefore is the inbred cousin of construction project management. In the world of software creation, project managers are a frustrated group.

In the software industry it is possible to have many different development methodologies that seem rational. The intellectual nature of creating software means that the process of creating it is not inherent in the product. The plethora of software creation methodologies and their practitioners is ample proof of this. The waterfall, spiral, iterative, ad-hoc, user driven, interaction driven, requirements driven, risk driven, budget driven, quality driven, calendar driven, market driven, technology driven, high ceremony and low ceremony variants all address different philosophies and practical considerations.

Anyone who claims the "One True Way" for software creation based on the construction analogy should be looked at with extreme skepticism. Even re-usable process frameworks such as the Rational Unified Process, should be looked at with some distrust.

Construction is Constrained

A construction project has many pre-determined constraints no matter what is being constructed. A building has a constraint of scale: it must be comfortable to humans. A building must respect physical laws otherwise it fails, potentially catastrophically. A building must often be made to tolerate a huge variety of environmental conditions. A building must be made of certain materials due to physical properties and availability. Construction must follow rules, regulations and codes imposed by parties well divorced from the actual requirements of a particular construction project. Actual construction work must occur in a specific physical location.

Software creation is not subject to the same constraints as construction. The intellectual nature of software means that it allows far more creative freedom. Complexity theory imposes very real mathematical constraints on software, but in practice, these constraints are rarely applicable or can be avoided using approximate rather than exact methods. Constraints of scale, physical laws, resource availability, external regulations and location do not apply or are much less critical for software than for construction. These different constraints mean that very different factors are considered when doing software creation versus constructing a building. These individual constraints and the differences between them are rarely if ever addressed when the analogy is made between software creation and construction.

Buildings are Completely Rigid

A building must have a design before you begin constructing it. You cannot move an elevator shaft after the fact. You cannot double the square footage after a foundation has been laid (even building higher would require changes in the foundation). Yet "analogous" changes can be made in software at almost any time. Building architecture and function are closely intertwined, software architecture and function are nearly independent. Undoing or changing physical construction, while possible, is hard and expensive. That's why when you want to renovate, you look seriously at moving to a new (better) home or office first. Undoing or changing software is easy and cheap, otherwise we wouldn't have a new version of Microsoft Office (tm) every couple years.

Software is fluid. It is possible to build software before even any formal requirements have been gathered. And that same ad-hoc software can then gradually be built upon, modified, broken up, incorporated into other software systems, fixed, broken, respond to changes in business, discarded, re-found, re-used, translated into a new programming language, wrapped up in layers, abstracted, productized and eventually sold to someone else. Software can be created, used and discarded in a matter of minutes or have a lifetime that lasts decades. Software projects build upon each other structurally in ways which construction projects rarely do.

The analogy between software creation and construction implies that software can be thought of very rigidly. However, in practice the fluidity of software is far to valuable to be ignored. Iterative development methodologies attempt to address this fluidity with various degrees of success but the very fact of iteration breaks the analogy with construction.

Pre-Fabricated Building Materials are Simple to Use

Human beings grow up in a physical universe where physical cause and effect are relatively obvious in many instances. In the case of structures this is particularly true. The ancients, without any complex math or physics, were able to create astounding physical structures from the pyramids to the cathedrals. This obviousness means that creating standard and re-usable pre-fabricated building materials is easy, and it is easy to use them. A steel girder has a fairly simple API: fasten both ends to a structure and put load bearing stuff on it. Nails, screws, cement walls (waffle-crete), joists, and cut lumber are all standardized and easy to use.

Software is incredibly abstract and often very arbitrary. Cause and effect are not obvious or intuitive despite programmer's best efforts. Examining another programmer's code with a mind to using it (let alone modifying it) is not a simple exercise. Even function or class libraries and toolkits such as the Java Development Kit are incredibly complex.

In software, there seem to be only certain things that lend themselves to re-use: simple data structures, simple algorithms, and sometimes simple abstraction layers and software tools. Other things, such as processes, components, third party "solutions", and frameworks can all be incredibly difficult to learn to use and then integrate into a software project. Re-use in software is hard.

It should be noted that software developers and engineers have a very generous standard for "easy-to-use". If it takes less than a couple weeks to become proficient with a new software library (e.g. JDBC or XML-DOM) then a software engineer considers that "easy".

It often seems that the effort to re-use software components is just as difficult as building needed functionality from scratch. Most components are generalized so that they can be used in a wide variety of situations - with the result that any given piece of software made from pre-fab components has a whole bunch of unused functionality left over - pipes that lead nowhere, half-walls and stairways to dead ends. That extra functionality often makes it difficult to learn about and use a component and adds substantially to the integration work. It also means that the cost of developing the component's functionality has to be recovered somehow. Creating the needed functionality from scratch is often more efficient. All the extra functionality of a generalized component is left out making it easier to learn and use, and it is perfectly integrated with the other parts of the system immediately. Those who promote the construction analogy in the form of component based development overlook the simplicity and intuitiveness of "components" in construction. Any analogy or methodology which deals with software components must explicitly recognize and address the incredible complexity inherent in the concept of software components.

The Humans Involved do Different Things

The human talents used in construction are different from those used in software creation. Software developers (architects, designers, engineers, testers, whatever) must work in an extremely abstract environment and at the same time deal with many more options. A press on a computer key can do literally anything it is possible to do with a computer; cause and effect are completely arbitrary. Yet pounding a nail always does the same thing. Software developers have the opportunity to be much more creative than their construction counterparts. Programmers are required to hold far more detailed and arbitrarily abstract information in their heads on a day-to-day basis than any construction worker ever does. Thus, trying to make a one-to-one correspondence between construction roles and software creation roles leaves many real and potential differences ignored. Just think about the actual differences between a software "architect" and a building architect or between a construction worker and a programmer. And is there any role in construction similar to a software tester? One might say that a building inspector is analogous, but the actual differences are huge!

The differences in talents required mean that management of software creation must be very different from management of construction.

Software is Fundamentally Different From Buildings

It seems there is something rigorous or logical about both construction and software development. The most obvious difference is that software is essentially intellectual whereas a building is essentially physical. This difference is often glossed over or given lip service when the analogy is made between the two. Even when the analogy is used deliberately and "scientifically" this difference between software and building is ignored or explained away as irrelevant.

Occasionally someone will point out this difference and even seem to discard the construction analogy because of this difference, but then go on to describe things that really are just new words for the same old analogy. Sometimes a few things are thrown in (like "iterative development") to try to distinguish the "new" approach from the construction analogy. Walker Royce of Rational Software wrote recently in Information Week an article that points out this basic difference between software and buildings (http://www.informationweek.com/story/IWK20020517S0002). However, in the article he discusses "architecture first", "component-based development", "design with rigorous ... notation", and "progress assessment" among other ideas from the analogy. As we can see, these are all problematic holdovers from the analogy.

The Construction Industry Has Problems Too!

Given all the fundamental and vast differences previously mentioned, there are still some software projects that might look like they are similar to construction projects and so some people will be tempted to say that the analogy is sometimes useful. There is one last issue that removes the desire for even that weak association between construction and software creation.

The construction industry has problems that are clear to anyone who cares to look. Construction projects go over budget, sometimes horrendously. Construction projects frequently deliver an imperfect building that fails safety, environmental or user requirements. If you have had your own home built, you will know what I mean! The construction industry has re-usable patterns, idioms, and parts, but there is a very clear dividing line between the intellectual constructs and the physical constructs. The as-built plans are always different from the architectural plans. And the reality of the construction site is that compromises are constantly being made even up to putting construction trash as filler inside walls! This is like deliberately putting bugs in software. It starts to sound like maybe construction projects might be just as bad off as software projects. These problems in the construction industry mean we should question the wisdom of trying to learn from the analogy between software creation and construction. Do we really want to learn how to construct software from an industry that has exactly the same problems?

So What Are We To Do?

Is all lost?

Yes, and no. The first thing to do is to once and for all discard the analogy with construction. Our decades of trying to use it have not taken us very far considering the incredibly bright minds that have been working on it. Instead we have to explicitly recognize the true attributes of software creation: its incredible flexibility, its odd economics, and the remarkable human talents required to create it.

Analogies are very powerful tools for understanding new concepts. If we can find a better analogy between software and some other realm, then we can improve our understanding of software. If our analogy is extremely deep and strong, me might go beyond improvement and uncover completely unexpected applications and techniques for software.

Extreme Programming

One approach that seems very promising is that of Extreme Programming. Extreme Programming or XP as it is known, is introduced in the book "Extreme Programming Explained" by Kent Beck. The web site www.extremeprogramming.org is another very informative introductory resource. XP is famous or infamous for its "pair programming" but in fact this radical practice is only one small aspect of many utilized by XP. XP explicitly looks at some of the underlying assumptions of software creation and comes up with some new things. Notably, the dogmic belief in the concept of "exponentially increasing cost of change" is challenged. The results of this challenge are some sweeping ramifications that affect every aspect of software creation. Unfortunately XP is missing a coherent analogy to some other realm of human experience. Occasionally mention is made of the creativity and skill of the programmer. This might lead us to an analogy in the world of media.

A Few Thoughts on a Better Analogy

The amazing thing about software is that each new software program or system is a completely new medium of expression. The difference between a game such as Quake III Arena where users can create their own worlds to fight each other in, and a simple text editing tool such as Microsoft's Wordpad is just as large as the difference between sculpting and writing with a pen and paper. No one would debate that sculpture and handwriting are two different media. Therefore software creation is the process of creating new medias.

This analogy of media creation is anticipated by Marshall McLuhan's famous quote: "The Medium is the Message." And so software creation is really communication as well. Alistair Cockburn discusses software as communication extensively in his book "Agile Software Development".

Further Reading and References

Extreme Programming Explained by Kent Beck

Extreme Programming Examined Giancarlo Succi and Michele Marchesi, ed.

Object Solutions by Grady Booch

The Mythical Man-Month by Fred Brooks

Software Craftsmanship by Pete McBreen

Agile Software Development by Alistair Cockburn

No Silver Bullet - Essence and Accidents of Software Engineering (http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html) by Fred Brooks

The Inmates are Running the Asylum by Alan Cooper

No Silver Bullet Revisited (http://www.virtualschool.edu/cox/AmProTTEF.html) by Brad Cox

The Cathedral and the Bazaar by Eric S. Raymond

No Silver Bullet II

(http://www.muq.org/~cynbe/rants/correctness2.html) by Jeff Prothero

Other Software Resources compiled by yours truly, Mishkin Berteig.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o (http://ww w.wwisa.org/wwisamain/phil.htm)
o (http://ww w.pmi.org/)
o (http://ww w.informationweek.com/story/IWK20020517S0002)
o www.extrem eprogramming.org
o (http://ww w.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html)
o (http://ww w.virtualschool.edu/cox/AmProTTEF.html)
o (http://ww w.muq.org/~cynbe/rants/correctness2.html)
o Other Software Resources
o Also by mberteig

Display: Sort:
The Software Construction Analogy is Broken | 117 comments (88 topical, 29 editorial, 0 hidden)
Moving elevator shafts (4.00 / 5) (#6)
by NFW on Thu Mar 13, 2003 at 10:32:43 PM EST

You cannot move an elevator shaft after the fact.

You can, it's just expensive. You can also redesign and reimplement software after it's written, it just costs less. Or, it looks like it won't cost much... It's still a waste of time though, if you missed an opportunity to do the design properly up front. It's also inevitable, if the person paying for the building or software didn't properly explain what they wanted before the work began.

To my thinking, the biggest difference between building development and software development is the clarity and precision of the requirements. Buildings have been built for generations, and people know what they expect from buildings. Someone who wants a building can sit down with a building architect and together they can come up with a specification. Things will change a bit before and even during implementation, but since the customer knows a lot about buildings and how they should look and work, the specification will pobably match the customer's desires pretty well.

On the other hand, someone who wants software written can sit down with a software architect and produce a "specification" that, in truth, does not adequately describe what the customer wants. This fact will not be apparent until the customer sees the first cut of the software. The cliched response: "um, it's just want I asked for, but it's not what I want." Then it's time to relocate some elevator shafts.

Extreme programming is all about coping with shifting specifications - making it easy to relocate elevator shafts. Classical software development - where you specify requirements, do a design on paper, and ship the first implementation to a satisfied custom - actually does work and it works really well. But, it requires a customer who actually knows what they want, and that's extremely rare. XP is a may to cope with customers who don't know what they want.

Gotta pick the right tool for the job, of course. Using XP when you could have gotten a good specification up front will result in wasted time. Using the classical model when your spec will be changing as the customer figures out what they need, will result in wasted time.

I'm not sure who's to blame for that - customers who let development begin before they (the customers) really know what they want, or developers who being projects without making sure the customer really understands what they're going to be creating.

Not all software projects fail because of weak specifications, of course, but that mistake does account for a lot of them.

Got birds?

Software Requirements (4.00 / 1) (#11)
by mberteig on Thu Mar 13, 2003 at 10:47:50 PM EST

In the projects I have been involved in, the fact is that even if a client knows exactly what they want before the software is written, the mere act of having those requirements reflected back to them in a functioning piece of software inspires new requirements. To me this is a communicative process that cannot be avoid without extreme and usually inappropriate effort.

Not all software projects fail because of weak specifications, of course, but that mistake does account for a lot of them.

I think instead of struggling against this reflective process (which we do because we are trained to think of software as construction), clients and software creators could do much better if they found the advantages and built on that process.

Of course, one thing I am firmly dogmatic about is that one must not be dogmatic :-) As you say: Gotta pick the right tool for the job, of course.

Agile Advice - How and Why to Work Agile
[ Parent ]
True (none / 0) (#12)
by NFW on Thu Mar 13, 2003 at 10:52:05 PM EST

Are you familiar with XP? It's an approach to dealing with that sort of thing.

Got birds?

[ Parent ]

Indeed... (none / 0) (#15)
by mberteig on Thu Mar 13, 2003 at 10:57:41 PM EST

I am very familiar with XP having initiated and run an XP project for a few months as well as years of working with most of the principles and practices of XP. The project was lots of fun, and honestly, I think that the principles and practices of XP really would get a lot of projects out of hot water. Unfortunately, the stuff written about XP that I have read (lots of it!) fails to capture the imagination with a real solid analogy for the process of creating software.

Agile Advice - How and Why to Work Agile
[ Parent ]
Two things (5.00 / 1) (#18)
by NFW on Thu Mar 13, 2003 at 11:02:27 PM EST

Firstly, by "XP" I mean "extreme programming," not Microsoft's latest OS.

Secondly, how often does a person pay for a house, then walk around in it for a while and say, "you know, this would be even cooler if it had a sunken living room, a spiral staircase instead of a straight one, and skylights in every room on the first-floor... how long would it take to make those changes?" :-)

I mean, you're right about the iterative process, but that process happens because customers don't know what they want until they've seen something that represents what they think they want. That's not such a huge problem with houses and office buildings.

Got birds?

[ Parent ]

We are all still Alchemists in this business (4.40 / 5) (#7)
by porkchop_d_clown on Thu Mar 13, 2003 at 10:32:46 PM EST

trying to turn lead into gold, crossing and recrossing the line between real science with its open communication and reproducible results, and pure wizardry, hording our secrets as we race to be the first to unlock the secret of the philosopher's stone.

Yeah, the building metaphor is dain bramaged. But it's better than the metaphor it replaced - programming as math. You also overlook the other metaphors used in other areas of programming: programming as modelling, and programming as rule-following are two easy examples.

The ugly truth is that programming is human thought codified and crystalized and, frankly, some of us are smarter than others and some of us think more like machines than others and sometimes we're just tired and write f'ing stupid code that ends up shipping to some poor customer. Metaphors, design patterns and coding styles can't replace actual intelligence but they help us to communicate to each other what it is we are trying to do - which allows us to support each other when we do run up against the limits of our own personal intelligence.

You can lead a horse to water, but you can't make him go off the high dive.

Other Metaphors (none / 0) (#13)
by mberteig on Thu Mar 13, 2003 at 10:53:44 PM EST

Indeed there are other metaphors out there that are more adequate than the construction one. The problem is that the construction (or engineering) analogy is used quite frequently as a bludgeon. I've seen clients, management and developers all use the analogy as an excuse.

So the purpose of my article, and perhaps this needs to be made more explicit, is primarly destructive: get rid of the construction analogy!!!

I would really like to someday write a book about a better analogy, but that is still a long ways off for me at least.

Agile Advice - How and Why to Work Agile
[ Parent ]
An honest question (4.50 / 2) (#24)
by carlossch on Thu Mar 13, 2003 at 11:35:52 PM EST

Why is it a better metaphor than programming as math? I can see many more parallels between programs and math than between programs and buildings.

"Programming is one of the hardest areas of applied mathematics", said Dijsktra, and I believe he is quite right. Some of the languages which are more used in critical-mission systems, like SML (it was used in the Paris metro system, IIRC) are all the more closer to math, and to me it is a good thing.

I agree with the rest of your comments, though. The cognitive load on a programmer which has to maintain some 10^5 LOC is pretty much unmatched in other areas. Yeah, rocket science is much harder, I know. But try telling your boss that what you're doing is damn hard.
-- He took a duck in the face at two hundred and fifty knots.
[ Parent ]

Programming is math (1.00 / 1) (#41)
by subversion on Fri Mar 14, 2003 at 06:45:12 AM EST

Only in the rare circumstance that your program is doing math.  The rest of the time, trying to think of a program as math will likely make your head hurt.

Then again, thinking of programming as construction makes my head hurt.  That's why I don't program anymore - they hire wage slaves for that these days.

If you disagree, reply, don't moderate.
[ Parent ]

Everything a computer does is math. (none / 0) (#91)
by bjlhct on Sat Mar 15, 2003 at 03:01:25 PM EST


[kur0(or)5hin http://www.kuro5hin.org/intelligence] - drowning your sorrows in intellectualism
[ Parent ]
The point of a metaphor is communication (5.00 / 1) (#43)
by porkchop_d_clown on Fri Mar 14, 2003 at 07:22:06 AM EST

And, yes, programming is a form of logic which is a form of math.

But most people find math hard to understand, so explaining programming in terms of math doesn't aid communication.

The building metaphor is an immense aid to programming because most people can visualize a building more readily than a continuously differentiable function.

The critical point is that it's still just a metaphor and, as such, only approximates reality. Having multiple metaphors in your kit is essential...

You can lead a horse to water, but you can't make him go off the high dive.

[ Parent ]
Concealing the math is not good (none / 0) (#107)
by carlossch on Tue Mar 18, 2003 at 01:46:20 PM EST

My problem with these sorts of analogies is that because programming is largely (discrete) math, there should be a considerable correlation between people who get math and people who are good programmers. I think one could even cause the other, but I am not sure, and can only speculate.

I know for sure that once I got a firmer grasp of math (university-level) I became a much better programmer. I agree completely on having multiple metaphors on your kit, though. I only think that concealing the mathematical element that is inherent to programming is a good part of the software engineering crisis.


PS: Sorry for the late reply, I was without net access for a few days.
-- He took a duck in the face at two hundred and fifty knots.
[ Parent ]

Subtle difference (none / 0) (#78)
by epepke on Fri Mar 14, 2003 at 09:55:10 PM EST

Why is it a better metaphor than programming as math? I can see many more parallels between programs and math than between programs and buildings.

Programs and math match well, metaphorically.
Programming and math don't.

The truth may be out there, but lies are inside your head.--Terry Pratchett

[ Parent ]
Programming is a subset of Math (5.00 / 1) (#61)
by bodrius on Fri Mar 14, 2003 at 03:03:41 PM EST

And because it is Math, it can be used as a universal metaphor for other things... any thing, except Math itself.

So Math cannot be a metaphor for programming. When programming was considered Math, it was essentially because we had to metaphor to deal with programming.

Of course, this situation would be 'a lousy metaphor' situation, but that's because usually alluding to supersets of knowledge don't make subsets easier to understand.
Freedom is the freedom to say 2+2=4, everything else follows...
[ Parent ]

nice post (none / 0) (#102)
by gdanjo on Tue Mar 18, 2003 at 12:49:18 AM EST

I agree with everything you say, except the fact that the building metaphor is brain-damaged. Here are some counter-arguments to the original article:
  • The distribution problem is common - for buildings, duplication happens at the planning stage. For software, custom-made software is as entrenched as the building that contains it.
  • Software is constrained. They're not the same constraints, but then again they're not the same activity.
  • Buildings are not rigid. Their floor-plans change, they are retrofitted when needed, and they are extended when needed.
  • Pre-fabricated software is easy to use. Libc seems to be doing fine, as well as the various microsoft "pre fabs." (we could use dirt to make buildings, but we use industry proven materials instead - similarly, there's bad libraries out there, but there is a enough quality software out there if you look).
  • Software creation includes the sysadmin (so we can CVS commit), the testers, etc. etc.
So, with the limitations of analogies in general in mind, what would be a better analogy?

That is, if I state "building software is like building houses", can you give me a more efficient, universal summary that would be better? Can you give me an XP analogy to make me understand what I'm missing out on?

Dan ...
"Death - oh! fair and `guiling copesmate Death!
Be not a malais'd beggar; claim this bloody jester!"
[ Parent ]

Another Analogy... Slavery (4.50 / 2) (#21)
by mberteig on Thu Mar 13, 2003 at 11:09:47 PM EST

Another analogy that I have been chewing on is that when we create software, we are trying to create the perfect slave. Software is about creating an entity with just the right amount of intelligence to do our bidding perfectly and instantaneously with none of the will to rebel against our requests.

That particular analogy is just a little too cynical for me to deal with in the main body of this particular article, but it probably deserves a good write up all on its own.

Agile Advice - How and Why to Work Agile
True (none / 0) (#63)
by bodrius on Fri Mar 14, 2003 at 03:16:53 PM EST

Although I'm not as skeptical of the benefits of the traditional project management approach as the author (yet?), the building metaphor is nonsensical indeed.

The only time I can think it makes sense, is by using your metaphor to solve the other metaphor...

The building is not the software, it's the DATA. The final state of your data structures.

The software are the workers.

Your work as a programmer, is to build the behavior of the workers, then get out of the way.

Once defined they will somehow, without supervision, put a bunch of bricks, mortar, pipes, cables, etc. together and come up with a fully functional building.

Notice there's no supervisor, no foreman, not even an architect. They're supposed to be unnecessary. No one is supposed to be there, not even take a look, until the workers report they're finished. Then there are no inspectors (that's also the workers' job), people just come to work and live in the building.

That's the problem with software. Unlike buildings, you don't have humans supervising other humans and correcting mistakes in the process, and even after the process. It's all non-supervised and the answer is expected to be flawless.

If your workers make mistakes, you don't get a chance to correct them. They just keep laying bricks blindly, and they do make mistakes, you won't notice until they finish the building, the construction collapses, or perhaps never.

Try building a house that way. Then remember we're pretending to build skyscrappers.
Freedom is the freedom to say 2+2=4, everything else follows...
[ Parent ]

So true... (3.50 / 2) (#73)
by benzapp on Fri Mar 14, 2003 at 05:01:56 PM EST

This is why pullies, levers, and wheels are considered technological marvels, whereas a build itself is not.  Perhaps technology is used in the building process, but the building itself is not technology.  

Technology is by definition, that which replicates human strengths or abilities.  You don't HAVE to use a pully when raising up those huge stone bricks, but you could do it with half as many people if you did. You could just drag that boulder accross the ground, but it would take you 100 people instead of 10.  Software does the same thing.  Whereas hundreds of clerical workers would be needed just to process records for a medium sized company, today a single secretary with a computer can do the same amount of work.  

What we are seeing with software today is a unique one.  Up until the computer age, all technological advancements replicated PHYSICAL human strengths, not mental ones.   These strengths are inherently simple, and less error prone.  Today however, we are trying to replicate the strengths of the human mind itself...   There is a certain element of hubris in our actions.  We naively believe we can create the perfect slave as you say, with all of our strength's and none of our faults.  

[ Parent ]

lot's of stuff wrong with it (4.80 / 5) (#22)
by khallow on Thu Mar 13, 2003 at 11:19:43 PM EST

First, you seem to be attacking a straw man argument. In the begining, "some people" seem to compare programming to construction. Then in the conclusions section, you ask "Is all lost?". Clearly, if a person their entire worldview on the premise that programming is exactly like building construction, and your arguments were accurate, then "all" would be lost. That group happens to be rather small.

Further, many of your arguments simply are without merit. For example, you state: "Construction is Constrained" and "Software creation is not subject to the same constraints as construction." However, software is subject to constraints as is building construction. Further, many of these constraints are very similar. For example, "Construction must follow rules, regulations and codes imposed by parties well divorced from the actual requirements of a particular construction project." Software often has to follow standards, upper management decrees, even rules, regulations, and codes.

Distribution of Buildings... Isn't

Buildings can't be distributed, but plans for buildings can be distributed and reused. I've been in homes seperated by hundreds of miles and totally different builders that had the exact same floor plan. Think about that.

Public vs. Published Interfaces

Ultimately, both programs and buildings must be built for use. These involve standard interfaces for a lot of stuff. For buildings, it would include restroom design, stairs, windows, doors, etc. The use of buildings can and is changeable.

Buildings are Completely Rigid

This is incorrect. You can move things around. You can even tear the building and put something new in its place - the most extreme form of modification. All you need to do is spend money and time. It would be more correct to say buildings are more rigid than software. Even so, it's very clear that planning ahead vastly reduces your costs associated with programming.

Instead, I think the real different is incremental improvements. These are much more difficult to do in buildings. Ie, a building that is 10% complete may be completely useless, while a software program that is 10% complete might be able to do a lot of work - the other 90% might consist of adding a host of functionality and improving the reliability to the core code.

Pre-Fabricated Building Materials are Simple to Use

The argument here isn't compelling. Why should I believe construction interfaces are inherently easier or less complex than programming interfaces? Seriously? I'm not arguing that construction interfaces are more complex than software interfaces, but that they are better designed and for that reason easier and simpler to use.

The Humans Involved do Different Things

One obvious difference is people don't manually run programs, but manually build and run buildings. And when we start comparing QA testing with building inspectors, are we really debating an argument that anyone cares about? The final conclusion there is pretty lame:

One might say that a building inspector is analogous, but the actual differences are huge!

And those differences are? And why are they huge?

Software is Fundamentally Different From Buildings

Excuse me, but "fundamentally different" depends on what is different. If I don't care whether the product built is via intellectual or physical means - say because those attributes are irrelevant to consideration of planning and design - then those differences aren't "fundamental".

The Construction Industry Has Problems Too!

Let's look at some construction problems you cite:

The construction industry has problems that are clear to anyone who cares to look. Construction projects go over budget, sometimes horrendously. Construction projects frequently deliver an imperfect building that fails safety, environmental or user requirements. If you have had your own home built, you will know what I mean! The construction industry has re-usable patterns, idioms, and parts, but there is a very clear dividing line between the intellectual constructs and the physical constructs. The as-built plans are always different from the architectural plans. And the reality of the construction site is that compromises are constantly being made even up to putting construction trash as filler inside walls! This is like deliberately putting bugs in software. It starts to sound like maybe construction projects might be just as bad off as software projects. These problems in the construction industry mean we should question the wisdom of trying to learn from the analogy between software creation and construction. Do we really want to learn how to construct software from an industry that has exactly the same problems?

Actually, based on what you say, the answer is "yes". Here's why. If the construction industry has "exactly the same problems" as the software industry, and learned how to fix them, then the software industry probably can use some of those same tricks.

A Few Thoughts on a Better Analogy

The amazing thing about software is that each new software program or system is a completely new medium of expression. The difference between a game such as Quake III Arena where users can create their own worlds to fight each other in, and a simple text editing tool such as Microsoft's Wordpad is just as large as the difference between sculpting and writing with a pen and paper. No one would debate that sculpture and handwriting are two different media. Therefore software creation is the process of creating new medias.

This analogy of media creation is anticipated by Marshall McLuhan's famous quote: "The Medium is the Message." And so software creation is really communication as well. Alistair Cockburn discusses software as communication extensively in his book "Agile Software Development".

This is a terrible analogy for several reasons. First, communication doesn't imply anything. For example, should we learn how to program from reading legal briefs in court cases or watching TV ads? Both are forms of communication in media. The problem with both media is that communication there is meant ultimately to coerce rather than to build. To use a construction analogy, a successful construction project involves good communivation between the clients, architect, builders, and regulators. The end result of that communication is a building that satisfies all parties.

Alternately, useful communication over a medium requires structure. When I post this article, it'll be labeled with my name. Other users can look up my past posting, diary, and story record. Finally, I even have an (outdated) biography that says something about me. This structure enables communication in the otherwise hypothetical Kuro5hin medium to occur. It is built not communicated.

A final comment. I do happen to think that the techniques of extreme programming would be counterproductive in construction. Programs are vastly more amenable to decomposition (or "factoring") and other incremental improvements. So there's something going for your article.

Stating the obvious since 1969.

Great Comments!!! (4.25 / 4) (#25)
by mberteig on Thu Mar 13, 2003 at 11:52:05 PM EST

First off, let me give you a huge "thanks" for the detailed comments!

First, you seem to be attacking a straw man argument. In the begining, "some people" seem to compare programming to construction. Then in the conclusions section, you ask "Is all lost?". Clearly, if a person their entire worldview on the premise that programming is exactly like building construction, and your arguments were accurate, then "all" would be lost. That group happens to be rather small.

Excellent point. My prose sometimes tends towards the rhetorical and sensational so I am glad that you pointed that out. I think I can remove that sort of thing and make the article stronger for it rather than weaker!

Buildings can't be distributed, but plans for buildings can be distributed and reused. I've been in homes seperated by hundreds of miles and totally different builders that had the exact same floor plan. Think about that.

I did think about it :-) But the fact is that moving a house after it is constructed is extremely expensive compared to doing the "same" thing with software. As well, duplicating a house means that the majority of the work has to be done all over again - house plans are cheap to make relative to the cost of building the house itself. With software, this cost structure is reversed so that duplicating software once it is built is almost trivially inexpensive.

Why should I believe construction interfaces are inherently easier or less complex than programming interfaces? Seriously? I'm not arguing that construction interfaces are more complex than software interfaces, but that they are better designed and for that reason easier and simpler to use.

This is a very good question and I admit to the weakness of my argument here. My question would be: is there any way to measure the ease of use of a component (physical or virtual)? I think that there is and it boils down to two factors: how much would it cost to build a specialized replacement for a component from scratch, and how much time does it take a reasonably compentent practitioner to learn to use a component. I unfortunately don't have solid numbers but here is my general understanding: building a girder from scratch (i.e. iron ore, smelter, etc.) each time you need one is extremely expensive compared to using pre-built girders over and over. This is partly because of the economics of physical distribution. Software is the opposite: because duplication is trivially inexpensive, the only cost difference is in the cost of buying one component vs. rebuilding it. Not only that, but the cost of the component has built in the cost of all of its flexibility and generalization. I leave the argument based on learning time to another discussion...

My "Humans involved do different things" section needs more research I guess. I can see what you mean by a pretty lame conclusion...

If the construction industry has "exactly the same problems" as the software industry, and learned how to fix them, then the software industry probably can use some of those same tricks.

But my point is that the construction industry has not solved those problems!

First, communication doesn't imply anything.

That's a pretty weak argument: communication implies a lot: we have both mathematical and social science theories of information and communication that could lend a lot to the issue of software creation. As an extremely quick example, what role does redundancy of information have, when is it useful?

So there's something going for your article.

Thanks! :-) I think so too.

Agile Advice - How and Why to Work Agile
[ Parent ]
After Over 20 Years as a Developer I can say (4.75 / 4) (#23)
by HidingMyName on Thu Mar 13, 2003 at 11:22:35 PM EST

The analogy to construction is very weak because:
  1. Building construction is a well understood process, with procedures and analysis developed over thousands of years. Computing is less than 50 years old. Thus our notation and approach are poor (it is like trying to do calculus with roman numerals).
  2. Software is discrete, hence it tends to either work or fail, not to have intermediate behaviors. Buildings are made of materials that undergo continuous deformation (assuming they don't break). With a building you can add material to strengthen it, adding code to a program doesn't tend to have the same effect.
  3. The conditions under which a building has to exist are typically better defined than the conditions under which many programs need to run. Combinatorial explosion precludes testing, and sometimes leads to hard to predict and degenerate cases. This is especially pernicious in timing and synchronization issues.
  4. Security is extremely hard because of the speed with which automation will allow remote attacks/exploits and the number of attackers and ease of remote connectivity. A house just needs to slow an attacker down until the owner can call the cops or deal with it themselves. A computer is harder to protect.

Computing is older than 50 years (none / 0) (#113)
by HidingMyName on Thu Mar 20, 2003 at 06:28:49 PM EST

Doh. I should have said electronic computing is less than 70 years old.

[ Parent ]
Your Experience? (4.00 / 2) (#26)
by mberteig on Thu Mar 13, 2003 at 11:56:57 PM EST

How often do people (managers, clients, developers) come across the use of the construction analogy in your regular work? I have personally come across it relatively frequently, particularly when dealing with project managers or when discussing software development methodologies.

Agile Advice - How and Why to Work Agile
mostly in abstract contexts (4.00 / 2) (#47)
by radish on Fri Mar 14, 2003 at 10:40:27 AM EST

I find that people (including me) use it pretty regularly when explaining something to a layperson, and in "what the hell is the executive team trying to ask for?" type conversations, but very little when discussing how to actually code something...

interestingly enough, although 1) my buddy Andy, also a developer, was a building contractor for years, and 2) I was very interested in architecture as a yoot (er, youth) before abandoning it for various other pursuits, our numerous conversations about programming hardly ever even touch on the construction analogy.

[ Parent ]

yoot (none / 0) (#57)
by mberteig on Fri Mar 14, 2003 at 02:06:54 PM EST

You don't happen to hang out with Persians do you? I also use the term "yoot" and I get it from mimmicing the pronounciation of the Persian contingent of my religious community.

Agile Advice - How and Why to Work Agile
[ Parent ]
LOL (none / 0) (#68)
by radish on Fri Mar 14, 2003 at 03:26:56 PM EST

the funny part is that while I do hang out with Persians, I got that particular habit from the movie "My Cousin Vinnie" (which has some hysterically funny scenes and which I recommend very highly...)

[ Parent ]
The two yoots! (none / 0) (#76)
by DominantParadigm on Fri Mar 14, 2003 at 09:17:33 PM EST

Yoot doesn't have nearly enough h's for those Persian gargles.

Caller:So you're advocating bombing innocent children? Howard Stern:Yes, of course!

[ Parent ]
Most Often in Translation (4.00 / 1) (#83)
by czolgosz on Sat Mar 15, 2003 at 01:49:18 AM EST

Like OldCoder mentioned in a previous post, the context in which this analogy most often appears is when programmers are trying to communicate what they're doing to non-programmers. Or worse, when hybrid beancounter/programmers are trying to show off their tech-savvy to the pure suits. Many are the cringe-makingly patronizing exchanges I have had to silently suffer through when my id was coaxing me to put the smackdown on the smarmy weasel with the MBA in "IT Management." Which sadly means "generic program management with a semester of COBOL or VB stuck on" at some institutions of higher learning where they really should know better.

Mind you, I really see no problem with the idea of project-managing a software effort. I've done it myself, several times, for money. The difficulty arises when the benefits of project management (or for that matter, of the methodology or architectural paradigm du jour) are oversold, and the client is led to believe that schedules are unconditional, that estimation of software level of effort is anything but fiendishly difficult and sensitive to far too many external factors, and that, contrary to experience and common sense, there are magic shortcuts to getting a system right.

Having said all that, I do respectfully disagree with the original poster about the "Buildings are solid" point. I've seen enough legacy code in long-running systems to believe that some code is in some sense set as solid as reinforced concrete, and it's certainly as hard to relocate or replace. The reason is that business knowledge is embodied in legacy code, then forgotten everywhere outside it, so there's a kind of information rigidity that sets in. The effort needed to re-engineer that code is analogous to the vast energy and knowledge needed to melt and recast a critical item of, say, structural steel. That part of the analogy, however flawed, seems meaningful to me.
Why should I let the toad work squat on my life? --Larkin
[ Parent ]
What is a building for? What is software for? (4.50 / 4) (#27)
by swr on Fri Mar 14, 2003 at 12:04:24 AM EST

You've missed what is in my opinion the most glaring difference between construction and software, and the part that makes software hard.

All buildings are required to do the same things. They need to stand without collapsing under their own weight, and contain people/things. There are a number of principles which must be understood to make that happen, but once that is understood, they apply to all buildings in more-or-less the same way.

If you write software applications that are as similar in function as the buildings construction workers build, you are wasting your time.

The whole purpose of software is the functionality. What it does. This is different for every piece of software. Two pieces of software that do the same thing, is generally redundant. Compare to construction, where ten appartment buildings offer ten times the usefulness of one appartment building.

Every software application is different. Every building is also different, but in comparatively minor ways.

Disclaimer: I am a programmer, not a construction worker.

Cool... (none / 0) (#28)
by mberteig on Fri Mar 14, 2003 at 12:07:40 AM EST

That's a really great point... do you mind if I integrate that point into the scholarly version of this article? If you are okay with that, how would you like to be attributed (e.g. by your k5 uid or by your real name)?


Agile Advice - How and Why to Work Agile
[ Parent ]
Be my guest (none / 0) (#71)
by swr on Fri Mar 14, 2003 at 04:32:50 PM EST

do you mind if I integrate that point into the scholarly version of this article?

Unless explicitly stated otherwise, I make no IP claims on my k5 posts. Use however you like. No attribution is required, but it is appreciated, in which case please use my k5 username (I like pseudonymity).

[ Parent ]
disagree (5.00 / 1) (#31)
by radish on Fri Mar 14, 2003 at 01:42:18 AM EST

not that the purpose of software is the functionality (although that's arguable too), but that all buildings are required to do the same things in a way that software isn't...

think about it.  at the most basic level it's true, but do you really want to live in a warehouse?  a gas station?  a garage?  a chemical plant?

[ Parent ]

living in a chemical plant (5.00 / 1) (#60)
by Shpongle Spore on Fri Mar 14, 2003 at 02:56:47 PM EST

Out of all the kinds of buildings that are made, there are only a few that I'd choose to live in, but if there was no alternative, I could live in just about any kind of building. Similarly, I could conduct business out of a house or store things in an office building.

Compare this to software...in a emergency, could you check your email with Quake instead of Outlook, or use gzip to compile some code?
I wish I was in Austin, at the Chili Parlor bar,
drinking 'Mad Dog' margaritas and not caring where you are
[ Parent ]

hm... right... excellent point (none / 0) (#65)
by radish on Fri Mar 14, 2003 at 03:23:35 PM EST

I didn't think it through all the way.  

specially the gzip part.  that might explain why my binaries occasionally compile to very small sizes but are totally nonfunctional :-)

[ Parent ]

pattern languages (4.50 / 2) (#30)
by radish on Fri Mar 14, 2003 at 01:26:36 AM EST

But my point is that the construction industry has not solved those problems!

modern software engineering, especially extreme programming and other "agile" methodologies, owe an enormous intellectual debt to Christopher Alexander, whose Timeless Way of Building series, particularly A Pattern Language (website) attempts to address many of the problems with construction which also exist in software engineering.

Tools (4.00 / 1) (#35)
by ComradeFork on Fri Mar 14, 2003 at 02:28:33 AM EST

One problem I see in developing software is the choice of tools. The tools chosen, such as the language, the library, the platform, etc. do have a significant impact on the actual development.

On one side, a company might spend all their time searching for the optimal set of tools, and on the other side, the company might simply a common tool which may be unsuitable.

On the whole, I personally think dynamically typed, very high level languages are actually a good thing for large projects (and yes, I am aware that statically typed languages might catch more bugs at compile time).

Purely as an example, a small but significant part of the problems of developing software could but solved by using a tool such as Twisted Python.

Statically typed languages (none / 0) (#66)
by truckaxle on Fri Mar 14, 2003 at 03:25:07 PM EST

I personally think dynamically typed, very high level languages are actually a good thing for large projects (and yes, I am aware that statically typed languages might catch more bugs at compile time).

I have never bought into the concept that statically typed languages catch more bugs at compile or link time. I sometimes think this is taken as gospel but I have never seen a study that quantified the percentages of bugs traced to a mispelled variable or mistyped data. Most bugs I encounter (or contribute) are algorithm in nature or simple things like those bugs that breed at input boundaries or "off by one" issues.

Some like it hot
[ Parent ]
Catching bugs at compile time (none / 0) (#70)
by swr on Fri Mar 14, 2003 at 04:23:24 PM EST

If a bug is not caught until it is encountered at run time, then it takes more effort to catch it, because you have to actually run the code and invoke all the paths. It's true that you have to do that anyway, but the more bugs you can catch at compile time the fewer compile/test/debug iterations you need to go through to get the rest. That can save a lot of time, especially in a complex application with a lot of possible paths.

[ Parent ]
Bugs (none / 0) (#74)
by ComradeFork on Fri Mar 14, 2003 at 06:34:06 PM EST

I think statically typed languages catch some bugs, but much less than people think, and the advantages of dynamic typing outweight those bugs.

[ Parent ]
I tend to agree (none / 0) (#82)
by mberteig on Fri Mar 14, 2003 at 11:11:06 PM EST

I really entered into the professional world of software development on the NeXT platform using Objective-C. Objective-C was really cool because it was dynamically typed if you wanted to use it that way (it even had real meta-class objects). You could also statically type stuff if you wanted. When I was exposed to C++ I just kept cringing over and over (and that still hasn't stopped :-). Java is about half-way.

As for bugs etc., I no longer think of the code-compile-debug cycle. Tools, IMHO, should always do incremental compilation so that your syntax/static type errors show up as you are coding. As well, mostly due to the wonderful book "Refactoring" by Martin Fowler, I have switched completely to a code unit test-code-test cycle instead. I find it much better. I have released significant multi-threaded, guaranteed-messaging code with zero bugs found in QA and production over two years by using that cycle.

Agile Advice - How and Why to Work Agile
[ Parent ]
What are the advantages? (none / 0) (#99)
by Cro Magnon on Mon Mar 17, 2003 at 11:54:28 AM EST

I've always thought dynamic languages were accidents waiting to happen. Admittedly, I've never written anything beyond very simple practice programs in any dynamic typed language.
Information wants to be beer.
[ Parent ]
Languages don't solve problems (5.00 / 1) (#105)
by Alhazred on Tue Mar 18, 2003 at 09:00:21 AM EST

If picking the right programming languages, or inventing them, was going to solve problems in software engineering, then we'd have solved them all long ago...

I've been programming now since the early '70's and I've seen a lot of CHANGE in programming languages, and the associated techniques of using them, but you know what? The failure rate on software projects hasn't budged. Not only that but you could  build the same programs in FORTRAN in 1970 that you can build in Java today.

Sure, there are improvements in how the software fits in with the rest of the world, and we've made things slightly more elegant, but the problem was NEVER tools, thats a myth that is just as pernicious as the 'software as construction' analogy.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]

No Analogies Please (5.00 / 15) (#38)
by OldCoder on Fri Mar 14, 2003 at 04:41:03 AM EST

Bunch of things to say. I've been programming, on and off, since 1965.

When you work in the industry, or in academia, on software, after two weeks you'll know more about software than about building construction. I've only met one person in my life who knew building construction before he learned programming. So the construction analogy is not used much within programming, but when communicating with nonprogrammers. The purposes of the construction analogy are several:

  1. To reuse pre-existing management techniques, like "Project Management".
  2. To reuse pre-existing language, like "solid", "project phase", "maintenance"..
  3. To explain things to people who know they don't know anything about software but imagine they know something about construction, due to pre-existing language.
  4. To fit into the management tools of budget and schedule; time, people and materials; up-front investment and profit. Construction of software and of buildings is a phase, followed by usage. In software, maintenance is more expensive... but the cost model sort of fits.
Builders build tens of thousands of gas stations, and millions of houses, not identical but not so different. Programmers build a few word processors, to get the thing right, and once a small number of products are selected, it is distributed cheaply. You touched on this but you weren't as clear as I'd like.

Software is digital and fragile. If there is one bug or one teeny hardware failure, a program that has been working for a long time can suddenly experience a catastrophic collapse. Most construction, including buildings and notably bridges, being analog, do not have single point failure modes. This was pointed out explicitly some decades ago, probably by Edsger W. Dijkstra. Yet software is modifiable after it is built. I have personally wrestled with projects where they continually changed the specs on me and were vague in the extreme. Modifying software gets very tough down the line. After a while it is more rigid than a house (which after all, can be moved) but less rigid than the Pyramids.

Software Engineering
The Software Engineering people have said a lot about this fragility and about analogies. You write as if you hadn't read enough about it. At one point, the goal of the "Software Engineering" discipline was to make Computer Programming as predictable and orderly as regular engineering, like chemical engineering or electrical engineering. These Software Engineering people didn't have an understanding of "Regular engineering", however, and their initial analogy was deeply flawed. Reading their initial essays, I remember thinking that they had confused real engineering with drafting, which was orderly. Then I realized I couldn't be sure how orderly drafting was, as I only imagined I understood it, having no experience in the field. And so it goes. The use of these analogies in the Software Engineering movement was, of course, to get funding from managers and grant giving organization, who were nonprogrammers. Especially back then.

The real differences between software development and other engineering disciplines is the body of technical knowledge underlying the other software engineering disciplines is at a more useful level. Chemical engineers learn chemistry and large number of industry stories and recipes. They all learn physics and calculus, and for some areas, such as linear circuit theory, the theory behind the engineering is amazingly accurate and useful. Software development does not have a body of scientific theory that is as useful. Our books of algorithms that are useful and widely applicable grow very slowly. The mathematicians have given us various verificationist technologies, but the last time I looked they were very hard to use.

The hardware (digital electronics) people tend to take an ever-varying type of component(tubes, transistor, gates, modules, integrated circuits, programmable arrays, optical thingies, quantum weirdness...) and make ever better versions of the same thing: Bits, control-flow, memory. The software people tend to take the same identical things, bits, control-flow, memory, in ever-greater amounts, and make radically different things, JDAM bomb guidance systems, web browsers, search engines, word processors, billing and accounting systems, shooter games...). I think this too was pointed out first by Dijkstra.

Analogies are a crutch. Eventually, everybody will be taught programming as soon as they've learned algebra, and we won't be forced to compare subroutines to drainpipe, and object broker frameworks to infinite pyramids of prefab housing within housing...

So don't bother dreaming up the perfect analogy. Get yourself past analogies into software development. Learn by doing. That's how the construction people did it. Can you imagine if the people who built the Pyramids had started by trying to think what kind of a stone was like a subroutine, and what kind of chisel was like what kind of abstract tookit? Madness!

Anyway, what's the digital version of analogy, digitary?

Management, not Engineering
The problems you are trying to address are problems of Software Development Management, not a literary problem of what simile to choose. The trouble lies in that management in general deals with projects in terms of the budget and the schedule, money and time; Everything has to plug into these Management Interface Sockets. Development of large software projects has to deal with communication, understanding, specification and its relation to testing, the decision to freeze the API (forever!), code small or code fast, standards vs proprietary, and so on. The external shell that software development presents to management does not fit well into the sockets management provides. It's all a big problem in interoperability. Analogies are the signal flags of communication, what we need are FibreChannels.

Where software development is like construction is that building construction also has to fit itself into these common management sockets, so something of the art of designing specialized adapters can be learned. But Hollywood has the same problem with script writers and directors, so the adaptation mechanisms they use might also be instructive. The case of the minimal adapter is probably manufacturing, where you bang out a zillion plastic water bottles over and over, all the numbers are known in advance (until oil prices change), or maybe writing insurance policies.

The Medium is the Massage
This book (title, not quote) was about the way the diffferent styles of media engage us, TV makes us passive, is usually pretty low key. Text in novels makes us work, can more easily describe wildly elaborate, exciting or improbable things. These differences help determine how we react to the media. I don't remember him describing the creative-industrial process, or complex. Also, you spelled it incorrectly.

A meeting without analogies is like eating dinner without a bicycle (a fish, however, is recommended).

By reading this signature, you have agreed.

Analogy's origins (4.00 / 2) (#40)
by subversion on Fri Mar 14, 2003 at 06:40:40 AM EST

Anyway, what's the digital version of analogy, digitary?

Analogy comes from the Middle English analogie, derived from the Latin root analogus.  This is also the source for the word analogue and analog, and all come from a common root meaning.

Analogue is usually used, at least within the US, only to refer to the 'similarity' meaning.  Analog can be used for either the 'similarity' or 'continuous variable' meanings.

The reason analog got pressed into use for CV devices is the proportionality property that made them useful - input is proportional to output in some fashion, hence output is an analogue of the input, hence them being called analogue (and soon analog) computers.

I know you didn't mean the digitary remark, but still.

If you disagree, reply, don't moderate.
[ Parent ]

Digitary (4.50 / 2) (#42)
by OldCoder on Fri Mar 14, 2003 at 07:00:37 AM EST

Twas a pun, should I have appended a smiley face?

You have refuted my entire article, and I am educated :-) Thank You.

On a more serious note, analog computers used analog, continuously variable, electronic components all wired to each other in glorious complexity. Each re-wiring (via a patch board) made the circuit implement, or simulate, a unique differential equation, and recording the output waveform provided the much-desired "Answer". Sometimes one would twiddle the knobs in an attempt to get the desired output, and then merely jot down the settings that worked, as the result of the experiment.

By reading this signature, you have agreed.
[ Parent ]

Analog computers (none / 0) (#62)
by subversion on Fri Mar 14, 2003 at 03:10:51 PM EST

I know.  I own a small analog computer, and have worked with a much larger one.

What I like about them is that they cost a lot less to buy than old analog synthesizers, and can often be modified to work in the same fashion.

I'm sorry if you didn't catch that mine was intended in a joking spirit.  So, here's my smiley, and we're all friends here.  :)

If you disagree, reply, don't moderate.
[ Parent ]

Your comment is better than the article. (nt) (none / 0) (#51)
by jabber on Fri Mar 14, 2003 at 01:05:39 PM EST

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"
[ Parent ]

I mostly agree... (5.00 / 2) (#56)
by mberteig on Fri Mar 14, 2003 at 02:03:49 PM EST

Indeed the problem of software development management is a crucial problem. However, I think that the more fundamental problem is the use of a broken analogy. I also think that finding a good analogy would be a big step forward. The analogy is really the foundation of thought upon which management principles and techniques are built. If we change the foundation, we can come up with new principles and techniques. To a degree, this is what the agile methodologies are all about (see the Agile Alliance).

It is true that construction is not the only analogy used as others have pointed out. But those other analogies are not really the subject of this article. In common discussion, the construction analogy is by far the most prevalent.

So don't bother dreaming up the perfect analogy. Get yourself past analogies into software development. Learn by doing.

Unfortunately, that doesn't fly very well in the business world. I have a full twelve years of professional software development experience. Does that matter? Not really... but what does matter is that in that time I have worked for nearly that many different organizations. The advantage of my experience is that it is very broad. I have worked in startups where heroics are the name of the game, and I have worked for the DOD on a 5-yr, 200 person project. I have worked in several industries. I've worked with RUP, XP, CMM, and more obscure methodologies and techniques. The one thing that is pretty much universal is the lack of a coherent set of principles that clients, management and developers all understand and work within. This lack of principles is, in my oppinion, due to the lack of a good understanding of the true nature of software.

The Medium is the Massage(sic)

Part of my academic background (an unfinished degree) is in Sociology, particularly communications and media. That particular catchphrase "The Medium is the Message" is one of the most mis-understood. The idea is that any given medium of communication is in fact a message itself (aside from the messages that it carries). That inherent message may be more important than the carried messages. For example, television doesn't just make us passive, it inherently requires a consumerist social structure in order to exist. So the message of television is not the shows we see, or even the fact that some types of programming are better suited for television. The message is that we need a society which supports expensive studios to create "quality" programming, and a large number of passive consumers of that programming.

With software, not only are we using a medium of communication (the programming language... which has its own message), but we are also creating a new medium with each program we create. We do not normally think about these programs in that way. (I believe that Game developers are starting to think that way.) TCP/IP is software (usually), and it provides a medium of communication. HTTP is software and it provides a medium of communication. Web browsers are software and they provide a medium of communication. What is the message of the Web Browser medium? (I don't know but I think it is an important question.) In an organization building some custom enterprise system, the question of that systems message may be very important but it is _never_ discussed. In fact, we don't even have a way to discuss this as far as I know.

Well, that was a big ramble. Hopefully there was something interesting in there :-)

Agile Advice - How and Why to Work Agile
[ Parent ]
Re: creating a new medium (none / 0) (#69)
by radish on Fri Mar 14, 2003 at 04:04:42 PM EST

that's an excellent point, and some excellent questions.  thinking about that, I'm reminded that in some ways we are (culturally speaking) in  wilder, newer territory than the human race has been in for a very long time.  I think this is part of what engine16 was getting at here

on the one hand, GUI consistency is a big deal.  the "medium" of a new program is almost certainly going to be a variation of the existing WIMP medium simply because that's what OSs provide.  but it can also be "new" and internally complete and provide a whole new possibility space in a way that doesn't really have any good analogy, especially if it's a "killer app".

I can't think of any parallel meme more recent than the development of scientific method...

[ Parent ]

The Importance of Software (none / 0) (#81)
by mberteig on Fri Mar 14, 2003 at 10:55:16 PM EST

Many people recognize that we are still in the infancy of software. We are trying so hard to play catch-up with the capabilities of our hardware, and with the short term needs of our businesses, that we have barely explored the communicative and artistic sides of software. That is something that has excited me since I was ten years old!

Programming languages are still very "difficult" to use as compared to the seeming ease of use of our natural human languages. Yet in my case, and with a few other developers I know, programming is just as effortless as writing or speaking. I think that once programming languages become more expressive both in their syntax and in their vocabularly, we will start to see the emergence of software as communication and art.

The construction analogy is something that is like a veil that blinds us to the potential of software. It blinds business people, managers and developers. It is a way of thinking about software that really eviscerates the core advantages of software.

Agile Advice - How and Why to Work Agile
[ Parent ]
You are .... (none / 0) (#103)
by gdanjo on Tue Mar 18, 2003 at 12:58:29 AM EST

... able to say with confidence that analogies suck simply because you have knowledge that makes the analogy useless.

For us young(er)-'uns, they are a god-send. They give me instant visuals as to what happens where, what processes are where, what to do when, etc. When the analogy fails, I am corrected. Eventually, the analogy is replaced by reality.

Infact, I assert that the analogy doesn't go far enough, since we do not use the the same terms as the analogy - this creates an un-needed level of abstraction requiring translation, which hinders the learning process.

Dan ...
"Death - oh! fair and `guiling copesmate Death!
Be not a malais'd beggar; claim this bloody jester!"
[ Parent ]

project management (4.50 / 2) (#45)
by Aimaz on Fri Mar 14, 2003 at 09:55:07 AM EST

In my experience, which i should point out is rather limited, if you have project management the programmers tend to fall out with the managers and the deadlines force shortcuts to be made, which introduce bad design and probably a good proportion of the inevitable bugs.

However if a group of programmers get together to make something it'll take alot longer, but because they aren't forced to think about it when they don't want to it is generally alot better software.


If a builder built a house (none / 0) (#67)
by subversion on Fri Mar 14, 2003 at 03:25:36 PM EST

Without having to worry about deadlines, doing it with a carpenter and electrician and plumber who were all doing it for fun, working when they wanted to, you'd end up with a damn good house.

Deadlines are a fact of life.  Project management techniques generally aim to make them as unobtrusive and reachable as possible.

Maybe programmers should learn something about project management before they work in large groups - engineers these days have a nearly universal requirement to take at least some basic project management coursework (often integrated into their technical communications courses), why shouldn't programmers learn the same things?

If you disagree, reply, don't moderate.
[ Parent ]

project management (none / 0) (#96)
by Aimaz on Sun Mar 16, 2003 at 09:12:46 PM EST

It is taught, in my uni at least both practically and theoretically.


[ Parent ]

Is it required? (none / 0) (#97)
by subversion on Mon Mar 17, 2003 at 02:17:49 AM EST

For engineers and programmers?  I'd be willing to bet that PM courses are required for civil engineers, but optional for others, and that the others (possibly excepting programmers - at my school, CS is not part of the engineering school so they get different requirements) will have some form of basic PM taught to them in their technical communications courses, or maybe in project courses.

If you disagree, reply, don't moderate.
[ Parent ]
Coding with pre-fab parts (3.00 / 2) (#46)
by krek on Fri Mar 14, 2003 at 09:59:41 AM EST

I have tried to explain this concept to many a project manager, but they just don't get it... Programming already has pre-fab components available to make your job easier.

They are stuff like: add, subtract, negate, and, or, xor, move, fetch, shift left, shift right, etc, etc...

Don't forget Quake [nt] (5.00 / 1) (#79)
by mmsmatt on Fri Mar 14, 2003 at 10:18:26 PM EST

[ Parent ]
sorry (1.75 / 4) (#48)
by turmeric on Fri Mar 14, 2003 at 10:45:46 AM EST

thats because software people dont know a goddamn fucking thing about building a building. the only reason it is 'easy' to them is because they hire a bunch of people to do it, whereas software they have to build themselves.

software is more like office bureaucracy (rules other ppeople have to follow, forms they have to fil out) than anything else.

Software and Office Bureaucracy (none / 0) (#88)
by OneEyedApe on Sat Mar 15, 2003 at 02:13:25 PM EST

Don't program much, do you? Most all programming I've done (C/C++, Common Lisp, VB, Java, and a wee bit of Perl) has a small set of basic rules (syntax) and the forms (functions) are simple and after a little while they become as familiar as the syntax. About a 1/3 of the time is spent trying to pin down the logic and structure of the code, and 2/3 is spent wondering what the hell the compiler means. Then again, there is a reason I don't claim to be a great (or even competent) programmer :).

[ Parent ]
uhm, im talking about what people do with the (none / 0) (#92)
by turmeric on Sat Mar 15, 2003 at 05:03:54 PM EST

finished product. the end product of software is a bunch of stupid rules and forms you have to fill out. the end product of building a building = a big house with walls and shit that you go inside and outside of. these are very different things, and the former is more like an office bureaucracy than a living space.

[ Parent ]
If builders built buildings... (2.75 / 4) (#50)
by buck on Fri Mar 14, 2003 at 12:52:10 PM EST

the way programmers wrote programs, the first woodpecker that would come along would destroy civilization.
“You, on the other hand, just spew forth your mental phlegmwads all over the place and don't have the goddamned courtesy to throw us a tissue afterwards.” -- kitten
Attribution, please. (4.00 / 1) (#75)
by it certainly is on Fri Mar 14, 2003 at 06:46:26 PM EST

Weinberg's First Law: Progress is made on alternate Fridays.

Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

Weinberg's Principle: An expert is a person who avoids the small errors while sweeping on to the grand fallacy.

Note: the joke only makes sense to people who live in wooden houses -- I'd never seen a wooden house (other than the shed in the back garden) until I visited America one year. I suppose it makes sense if you don't live anywhere near a quarry.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

Hmm.... (2.50 / 2) (#53)
by RofGilead on Fri Mar 14, 2003 at 01:26:47 PM EST

My friend told me that programming is like warm apple pie. Mmmmmm... warm apple pie.

-= RofGilead =-

Remember, you're unique, just like everyone else. -BlueOregon
If I ever make a language... (none / 0) (#85)
by carbon on Sat Mar 15, 2003 at 04:59:22 AM EST

...I'll call it the 'Pie' language. It will have a GUI kit called 'Crust' and an interface to the C API called 'Filling'. If it ever gets forked, then the fork will have to be called 'Bakery' (or maybe 'Fork').

Everyone likes pie.

Wasn't Dr. Claus the bad guy on Inspector Gadget? - dirvish
[ Parent ]
The compiler should be "bakery" (5.00 / 1) (#89)
by sophacles on Sat Mar 15, 2003 at 02:35:29 PM EST

[ Parent ]
Perhaps "grandma" <n/t> (none / 0) (#95)
by carbon on Sun Mar 16, 2003 at 02:24:16 AM EST

Wasn't Dr. Claus the bad guy on Inspector Gadget? - dirvish
[ Parent ]
Other Big Flaws -Building Codes -Quality (5.00 / 4) (#55)
by n8f8 on Fri Mar 14, 2003 at 01:51:23 PM EST

In the comparison I would relate Building codes to software requirments and risks. If a builder had to deal with Building Codes that change every day then the job would become exponentially difficult. Software developers have to deal with ever-changing hardware and operating system environment changes.

Another thing to note, and this comes from growing up on a construction site,is that the amount of slop/defects that are allowed in the construction process is relativly large. Measured to any finite degree ever house and building had crooked walls. For the most part these aren't even considered defects. The big difference with software is that interconneted software modules have very little tolerence for defects whereas few buildings would collapse if any one component were off by 1% from the design criteria.

Another thing to note is that the life expectance for a building is at least 30 years. The lifetime for most software is less than two. Yet we seem to spend more time developing processes for software development than the vast majority of all construction fields do. What we seem to suffer from most in the software field in an overabundance of inbred thinking. Pinheads like to turn good ideas into a religion. So in the end we end up going from one fad to the next with the a catchy buzzword software process method always on the horizon.

Sig: (This will get posted after your comments)

software analogies (and patterns again) (5.00 / 2) (#64)
by radish on Fri Mar 14, 2003 at 03:18:12 PM EST

I don't think that the construction analogy is inherently broken, just overextended.  it works in some ways and not others, like any analogy, and I'll try not to overuse it here, but I'd like to borrow the "long comment with bold subheads" format to throw out my own ideas ;-)

A Better Analogy?
my preferred software analogy is actually mechanical engines, though construction and organic life seem to work pretty well, perhaps just because I know more about those.  the resource constraints on software development are almost all labor related, so you get the Rube Goldberg effect - pieces and parts that interact dynamically are cheap, so they tend to proliferate.  I use the engine analogy (hopefully) to bring me back down to Earth.

mechanical linkages are more difficult to explain verbally however, and architecture and life have an immediacy which makes them valuable for conveying ideas.  they are also much more accessible.  nearly everyone has seen a building go up, but not many people have seen a machine shop.

Design vs. Implementation
software design and software implementation tend, for better or worse, to be very different critters.  even assuming that you have an architect who actually knows something about coding (what a treat!) there is always some sort of collision with reality.  

in fact, I would say that the more of a boundary there is between the design phase and the implementation phase, the more useful construction and mechanical engineering analogies become, but as OldCoder pointed out, this seems to have more to do with management and planning than development itself.  

Learning From Tinkers and Tailors
as you say, construction commonly uses "hard" (aka expensive) resources in a way which requires up-front logistical analysis and economic investment.  in turn, knowing how many 2x4s to buy and where to ship them requires a complete specification.  this is the reason that Big Design Up Front (BDUF) is the norm in large construction projects and most large software projects as well.

so software development is definitely like "putting things together in a stable way", but the "things" aren't so inherently valuable.  their value is in the way that they're put together, more like a tinker fiddling around in the garage, or a tailor making himself a new suit from scraps.  or a beach house built piecemeal with driftwood, though the analogy starts to get thin at that point...

agile methodologies (which I favor, coming as I do from a non-enterprise background) try to mitigate this by applying the more natural logistical path.  since the team and their computers is the main "hard" resource, you don't have to know nearly as much about the finished product before you start working, and by actively embracing that fact you get to be much more responsive to inevitable changing requirements (agile, in a word).

Learning From the Oregon Experiment
I am appalled - appalled I say ;-) - at the lack of historical perspective in this thread.  A Pattern Language is the very profound and tremendously influential book which introduced (formally at least, but see below) the notion of an abstract pattern language.  pattern languages are now the de facto model by which the primary drawback of adaptive (agile) construction (development), it's lack of overall structure, are mitigated so that its benefits can be reaped.

what good is a pattern language?  well when you build a building or write a program, your design strategy falls somewhere along the spectrum between "design every detail before you start fabricating" and "design nothing - start fabricating".  each approach has advantages, but most software, and most forms of construction, are for direct use by non-expert humans, so too much up-front design is a great liability.  humans are fickle, changeable, they often don't know what they want until they see it, their ability to model the desired result even in their mind varies widely, let alone their ability to communicate it.  and that's just the experts.  the non-experts - the clients - have even more trouble.

Building a Better Whatsit
so there is great value in an adaptive design strategy, because adaptiveness is a hallmark of human behavior.  unfortunately, an adaptive strategy without an overarching principle to give the final product some overall structure tends to lead to "clumps" (either functionally or literally) which fall apart.  a good whatsit generally needs more than glue for the pieces, it needs some structural integrity as a whole.

enter the pattern language.  the idea started, roughly speaking, as a way to convey elements of architecture and urban planning which have been consistently successful and human-friendly over long periods of human history.  the "pattern" in a pattern language is a description of, and commentary on, some recurring element or phenomenon within a certain realm, be it construction, software, or double entry accounting.  the "language" is simply a (frequently hierarchical) collection of interrelated patterns which attempt to encapsulate the "craft" as it has evolved or emerged over time.

a pattern language is, in effect, a system modeling kit in the most abstract sense.  it attempts to be a reflection of knowledge that experienced practictioners take for granted.  by taking each step observing, using, and adhering to the relevant pattern(s) and the interrelations between them, it becomes easier to start fabricating a minimal design immediately with a greatly reduced risk of a catastrophic structural failure later.  the pattern guides you and gives you access to the experience of other fabricators and designers without constraining you to a pre-existing design.

thus, while I agree that the construction analogy per se is somewhat broken and frequently misapplied in practice, I think that there are many abstract principles which can safely and fruitfully shared between construction and software engineering, as well as even more diverse fields.  YMMV :-)

Yes and no (5.00 / 1) (#72)
by MajorMajor on Fri Mar 14, 2003 at 04:45:38 PM EST

I feel qualified to write on this topic, since I am a software developer, and have also worked on construction sites. Duplication of buildings The construction industry differs from software in that most buildings are either bespoke, or made in short runs (kind of like a custom or very specialised app). e.g. most offices.

However, many buildings are repeated pretty identically many times, think of terraced houses, warehouses in business parks, sheds, garages etc. Of course, the number of copies is much smaller here.

It's nonsense to say that software has no aesthetics - I would hope that most software engineers have a sense of what aesthetically pleasing code looks like. On top of that there is the external interface, whether console or GUI, which should also look and feel right, whilst conforming to whatever style guidelines exist.

Whilst architects may design the building/sofware to be "just right", the people who actually code/build it have to get round the practical problems of time, materials constraints, and bits that the architect just plain didn't consider.

interfaces Well, here the analogy gets a bit strained maybe. I guess the interfaces of a building are the bits you actually use - the lifts, doors, stairs, where the rooms are, access gates etc. These are usually pretty well specced. since humans have pretty much figured out how they like things in the buildings department. But buildings don't use other buildings, in the way that software does, so these are more like part of the UI.

Project management

Sure, for big building projects, the formal project management is what's followed, with minor deviations usually. But anyone who's seen episodes of Changing Rooms knows that for more individual projects, sometimes the client doesn't have a clue what he wants. I'd guess it would be true for most large software projects to have a fairly well structured set of project phases - certainly the company I work for tries to follow this practice, even if it doesn't always end up being a textbook operation (hey what is?)

Buildings are completely rigid

I have to disagree here. I've been on sites where the contractors have cocked up, and walls/air ducts have to be taken down and rerouted, the pipes are connected up all wrong. The reason buildings look rigid is because the expensive bits to change - the solid things that get put in first, aren't changed once they're in. It's the same with software. Vendors try to avoid at all costs putting out patches after the product has shipped, because every patch has to be tested, and supported. Of course, lots of things are not fixed, both in software and construction, that's why the air conditioning in my building breaks down every month, the ceiling has damp patches, and the swipe card doors are always breaking - they were never specced properly. Oh yeah, and the reason why the network cabling doesn't go where the patch panel says it should.

Buildings handed over to client before they're really done? Of course, been there done it.

Pre-fab building materials

The main difference here is that pre-fab materials are usually over-specced so that they can be used in a wide variety of situations. Sometimes they're not up to the job, but on the whole they do what you want, just not as well, simply because there are only a limited number of physical operations possible. With software, it either does what you want, or it doesn't and you code around it if you know how it doesn't meet your criteria, or you use it and you have a bug.

Alexander's Design Patterns and Software Design (4.50 / 2) (#77)
by kyfung on Fri Mar 14, 2003 at 09:35:07 PM EST

One of the reasons for the popularity of the construction analogy is probably the influence of Christopher Alexander on the design pattern movement in computer programming. His books on construction, not just on design patterns, mind you, are fascinating. I am eagerly awaiting his latest four-volume book on the nature of centers.

However, I agree that the construction analogy is mostly not very useful. Even the application of design patterns as Alexander saw them might not have the near holy grail status some software developers deem it has. And of course, Alexander himself does not seem to think patterns to be the end-all any more. Before the publication of his latest books on the concept of centers, you will have to learn about 12th century Turkish carpets to get a feel of what he thinks about construction now.

Alexander thinks that our houses and indeed our neighbourhoods should be constructed, repaired, and extended by us, the people who live in the houses and the neighbourhoods, not by syndicates of builders and banks. Of course, commercial buildings will be an entirely different thing. I believe this is also valid in software development: the biggest problem with software programs is not that they have bugs. After all, we have leaky faucets too. The biggest problem is that we are more or less hopeless in fixing the programs ourselves (meaning people who are not programmers, and indeed also programmers when faced with programs with closed source). Of course, programming is totally out of the question for most people.

To allow ordinary people, in constrast to only programmers, to construct, repair, and extend programs, writing programs, fixing bugs, and adding features to programs should probably be more like construction: not as complex. Construction is not as complex only because we only deal with the construction materials and techniques at human scale. On the other hand, programming is still pretty much sub-human scale. It is like trying to construct wood, steel, and other building materials on the molecular level every time we are building something. Of course we would get many more things wrong. (With modular and object-oriented programming, we are like given molecules to work with, rather than atoms. A big improvement, to be sure, but nonetheless sub-human scale to be useful to vast majority of people).

As long as we program on that level, development processes, philosophies, religions, cults, disciplines, etc., are simply stopgap measures.

Thanks (none / 0) (#80)
by mberteig on Fri Mar 14, 2003 at 10:30:08 PM EST

Just wanted to put out a general big thanks! to everyone who has take the time to post comments. I really appreciate the excellent points that everyone is making. As I mentioned in an editorial comment, this article is a substantially abridged version of a more scholarly paper I am working on. I thought it would be of interest to many on K5 so I put it out there at this stage. Admittedly there are some significant weaknesses some of which I was already aware of, and some of which you have pointed out to me. I also really appreciate the encouraging and supportive notes and comments that several of you have made.

Thanks again!

Agile Advice - How and Why to Work Agile
Joel said it more succinctly (4.66 / 3) (#84)
by marktaw on Sat Mar 15, 2003 at 03:41:47 AM EST

The unique thing about software is that it is infinitely clonable. Once you've written a subroutine, you can call it as often as you want. This means that almost everything we do as software developers is something that has never been done before. This is very different than what construction workers do. Herman the Handyman, who just installed a tile floor for me, has probably installed hundreds of tile floors. He has to keep installing tile floors again and again as long as new tile floors are needed. We in the software industry would have long since written a Tile Floor Template Library (TFTL) and generating new tile floors would be trivial.

(OK, maybe there would be six versions of the library, one for Delphi, one for perl, etc. And some sick puppy programmers like me would rewrite it. But only once, and I would use it everywhere I needed a tile floor, and I would try to convince my clients that their back lawn would look really nice with tile instead of grass.)

In software, the boring problems are solved. Everything you do is on the cutting edge by definition. So by definition it is unpredictable. That's why software has more of a science nature than a construction nature.

from http://www.joelonsoftware.com/news/fog0000000337.html

same thing? (none / 0) (#104)
by gdanjo on Tue Mar 18, 2003 at 01:15:44 AM EST

[...] almost everything we do as software developers is something that has never been done before. This is very different than what construction workers do. Herman the Handyman, who just installed a tile floor for me, has probably installed hundreds of tile floors. He has to keep installing tile floors again and again as long as new tile floors are needed.
Isn't this the same thing as cloning? It's worse in one respect - time, effort and money - but it's better in another - clones are usually better than their "parent."

(I'm talking about the process, not the phisical stuff)

Dan ...
"Death - oh! fair and `guiling copesmate Death!
Be not a malais'd beggar; claim this bloody jester!"
[ Parent ]

Analogies are for the lazy (5.00 / 2) (#86)
by TheSleeper on Sat Mar 15, 2003 at 06:47:37 AM EST

I'd like to ask the people who promote the "Software construction is like building construction" analogy this question: How did all the formal roles and rules and so on that exist in the field of building construction come about? By analogy? Did the people who were building edifices look at some already existing field and say: "Putting up buildings is a lot like that field. We need to borrow concepts from that field." Not really, I'd wager. The concepts in building construction were developed over a long period of time by people who looked at the various economic and technological realities of the situation, and came up with appropriate ways of dealing with those realities. The same thing needs to happen in software, not a quick-and-dirty resort to "reuse" organizational structures that were designed for a very different set of requirements and realities.

I think that a lot of the people peddling these analogies are little better than snake-oil salesmen. They're trying to tell CIOs and VPs of Engineering and so on what they want to hear in order to make a buck, either by selling lots of books, or by selling their consulting services. The analogy sounds more like a sales pitch than anything else.

And I also think a lot of the people interested in and talking about architecture are simply trying to carve out a higher-status position for themselves, to elevate themselves above lowly grunt coders in the way that an architect has higher status than a carpenter or bricklayer. Certainly there's a fair amount of smug looking down the nose at coders in the linked article.

None of this should be taken to mean that I think there's no room for people doing design at a higher level than that of the guy pounding out subroutines, or that everyone who writes about ways to improve software development has ulterior motives. Just that it's worthwhile to carefully consider the motives of these would-be architects.

Another Book (5.00 / 1) (#87)
by avdi on Sat Mar 15, 2003 at 09:29:16 AM EST

I was surprised not to see, among your list of excellent resources at the end of the article, a reference to The Pragmatic Programmer, by Dave Thomas and Andy Hunt. They make a point of addressing the flaws in the "Software Development as Construction" analogy, pointing out that creating software is a much more organic process than construction, more akin to gardening than building. Of course, Steve McConnel also has some convincing things to say about the innaplicability of the farming analogy in Code Complete, another fine book, but as I think all of the above programmers would agree, all paradigms are leaky past a certain point, and cannot be applied indiscriminately.

Now leave us, and take your fish with you. - Faramir
Not just wrong, but misplaced. (5.00 / 2) (#94)
by rrsipov on Sat Mar 15, 2003 at 11:40:06 PM EST

I forget where I read this, here goes my summary of the best way to "refute" the software as construction analogy. In construction all (at least ideally) of the design work is done up-front, and most of the actual cost is incured in non-design related activities, such as buying the land, the materials, and doing the actual construction work. In software, if you want to try and use the construction analogy you need to realize that thinking of programmers as construction workers is misplaced. The compiler takes the places of the construction worker. Programmers, at least on successful projects, are in actuality part of a continuing design process.

You want analogies? (5.00 / 2) (#98)
by Anonymous Hiro on Mon Mar 17, 2003 at 09:05:11 AM EST

Nah it's not that broken.

The real problem with software compared to the building industry is:

You can actually launch the blueprint! And many people actually do it. It compiles it runs etc. Guess what even more people are actually willing to pay for it. It's like getting away with selling the 3D Autocad design of the building as the real thing ;).

And even if you don't, you or the boss gets very tempted to launch the nice little plastic model of the building when it's done.

Typical software:
Version 1.0 - the blueprint
Version 2.0 - the plastic model
Version 3.0 - actual building.
Version 4.0 - renovations.
Version 5.0 - redecoration.

So have I got it wrong? Well even if I have, I haven't spewed hundreds of words for you to wade through :).

Don't forget: bridges, skyscrapers, dams etc aren't all that easy. It's not all low cost flats y'know.

Software construction vs building construction (none / 0) (#100)
by ericgu on Mon Mar 17, 2003 at 05:26:10 PM EST

As a long-time developer and serious amateur carpenter (currently finishing a house), I'd like to share my perspective. The big fallacy of this comparison is that building is a smooth, ordered process. Anybody who has had a house built can tell you that this isn't really the case. It's really common to have to redo plans because of rulings from the county, or because the land isn't quite the way you expected. Or maybe the plumber puts his pipes in the location the electrician needed, or the architect put in a door that blocks the hallway when it's open. It's an evolving process, much like building software is an evolving process. It is true that in the construction industry there are building codes that are generally sufficient to keep a house from falling down. This helps, but it's fairly easy to do poor quality work that meets the code, or even to do sub-code work that the inspector misses. It's also true that, like software, many of the big problems in a house aren't visible when it's finished, but only show up later. I think creating software and building houses are both examples of crafts, and they require skilled craftsmen to get a good result. So I guess I'm saying that I think the analogy is fairly good.

Wrong Analogy? (none / 0) (#101)
by Alhazred on Mon Mar 17, 2003 at 06:06:45 PM EST

The question is, is construction that useful an analogy. Just because building and coding are both crafts (which I can agree with) does not mean that they have ANYTHING else in common. I mean hand-throwing ceramic pots is also a craft, but how much can you learn about building a house from that? Certainly craftsmen tend to share certain attitudes, at least the successful ones, but I think the argument that the construction industry is a good template for the software industry is very weak. Heck, if the analogy was a GOOD one, then how come we are still basically hardly any better at building software than we were in the 1950's? Eh? Sure we have GUIs now, but honestly if you go back and look at what they were doing 40 years ago, we haven't progressed much.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
People think they understand software development (5.00 / 1) (#106)
by Robb on Tue Mar 18, 2003 at 09:22:43 AM EST

In software the step from source code to working program is almost completely automated. If we want to use the building analogy then it would be like having a team of really efficient but stupid robots that once you give them the plan they do everything else.

Since people do construction and not robots the design of a building is never completely specified. Architects use guidelines to help them think about where and how electrical systems and plumbing are integrated into a building but they do not specify every little detail about each of these systems. In contrast if the construction was automated then someone clearly would need to do this kind of detailed design before construction starts.

So, if we define constructing a software system to be the act of taking the design, i.e. the source code, and creating an artifact, i.e. an executable program, then the analogy falls apart completely. In software design costs are high and construction costs are negligible compared to design costs. In buildings neither construction nor design costs are negligible but construction costs are typically greater than design costs even if we don't take into account the required building materials.

The only value of the building analogy is to show people just how wrong many of their intuitions are about software.

Insightful! (none / 0) (#111)
by mberteig on Wed Mar 19, 2003 at 12:37:04 PM EST

This is extremely insightful and well put - thanks!

Agile Advice - How and Why to Work Agile
[ Parent ]
The source code is the product, not the design (5.00 / 1) (#117)
by ScotC on Thu May 15, 2003 at 12:04:41 PM EST

So, if we define constructing a software system to be the act of taking the design, i.e. the source code, and creating an artifact, i.e. an executable program, then the analogy falls apart completely.

I think that's exactly why that is not the definition most people use when making this analogy. Because the creation of the executable from the source code is so automated, it is more realistic to define the source code itself not as the design, but as the end product. That's why the article compared software engineers to carpenters. Using the definition above, you'd have to compare the compiler to a carpenter, and the people writing the code to architects, which doesn't make sense.
It's still a flawed analogy, but I think it's being misinterpreted.

[ Parent ]
The real problem is Software Quaility (5.00 / 1) (#109)
by lukme on Wed Mar 19, 2003 at 11:43:17 AM EST

The analogy is not important so long as software quailty improves.

One thing that I have observed is the companies which have the worst software quailty don't regularily use their software and have the fewest automated tests.

Of the companies that I have worked for, the company with the highest quality software had all the end to end tests automated, and they were run frequently - at least once per week. Furthermore, the application was used on itself. This application was written explicitly for programmers and software quality asurance (SQA) people, and the company didn't have a SQA group.

The company with the lowest quality software was completely unable to run an end to end test of their software, and with the limited tests they were able to do, the results were always different than in production. This application was written for government, in compairison, this company had a SQA group.

Simple question - how many of you have made a similar observation?

It's awfully hard to fly with eagles when you're a turkey.
Testing (none / 0) (#110)
by mberteig on Wed Mar 19, 2003 at 12:35:47 PM EST

I completely agree that automated testing is one of the most important, if not the most important, contributors to software quality. I use JUnit extensively while doing my own coding work. On my current project, I am responsible for developing a functional test harness for our messaging-based system. This will be the first automated system available in the organization, and if it is used, it will improve quality by a large degree.

However, as with all things, quality is only one consideration and one can have too much quality to the detriment of other important factors such as functionality, time-to-market, performance, project cost, etc. Coming up with a good analogy could, theoretically, help to balance these seemingly conflicting considerations and may even provide a way to reconcile them.

Agile Advice - How and Why to Work Agile
[ Parent ]
Extreme Programming (none / 0) (#112)
by cypherpunks on Thu Mar 20, 2003 at 05:56:44 PM EST

Can someone please show me a scenario involving a number of specialists working together on a software project where extreme programming has value? I've heard the arguments again and again about how leet extreme programming is and how it's the ultimate software development methodology (a phrase which automatically sets off alarms for me) and I've never seen how it could apply usefully to a case where you have a group of specialists working together. Especially when those specialists share little common knowledge.

The problem with commercial software (none / 0) (#114)
by ToughLove on Fri Mar 21, 2003 at 10:54:33 AM EST

Not only is it regulated by the department of commerce {ie.. make a backdoor, or you can't put it on the market}, but the fact is their is too great of incentive to exploit users and have them click their rights away! AFter all, information gained by manufactures of software and is sold to Big Bro and anyone else who wants to pay them. You see by businesses violating your rights to privacy{backed by contract law} and in turn selling the info to the government, big business has effectively circumvented our constitutional rights{with the help of our friendly legislatures}. As long as there are stupid people who run proprietary applications, there are "insiders" who have one up on your business.

the construction analogy lacks vision (5.00 / 1) (#115)
by metagone on Tue Mar 25, 2003 at 06:05:34 PM EST

the journey analogy is better in my opinion. there is a destination which is final product. and there are all the steps inbetween from where you are to where you want to be. each step is a resource. resources come in all shades and colors. some are problems, and setbacks, and bugs, and bad code. others are tools, and skill, state of mind, food, drink, sleep etc.

treat the software development process as going on a very long trip. you have a vague but solid idea given to you by the design team working with the client of the working software. you know that you can not pack everything and the kitchen sink into your backpack (or production computer) so you must start taking only the important things. those important things are what you will need for the journey. but you do not need all those things immediately, and somethings you might discover as you go. say you stop in a small town and it turns out they have a better car or motor bike or something better (production systems do get better every year). this makes your journey easier. and because you are not cluttered with the kitchen sink you have to be constantly creative with what you have. this is skill and craftsmanship. as you travel you got to keep trying to get to the destination. you can not just decide to go off the path. though sometimes you might realize that to get to where you want to be requires more than you yourself can give. try getting to mars by yourself. ask for help. there is no shame in that. meet fellow travellers well. swap stories (or code or dev tool tips). etc.

do remember that sometimes a journey has a lot of initial planning, think of trying to go to mars or some environmentally dangerous place. but even then, they can not fit in everything and the kitchen sink. well, they can fit the kitchen sink, but you can not take everything with you. at the very least there are storage issues. how would you get the whole of china on one ark-style ship and shoot them off to a far away star? what do you need? will you be able to pack everything? what if you meet the cartoon aliens from venus? they have pole-zero ray guns. do you haev shields for those? i mean, those ray guns do not operate using the same laws of physics. what i am getting to, is that we are not gods. we can not control all the environmental factors. some of them we have to live with. others we use to our advantage. gravity is one such factor. accept it and move along. do not dwell for too long on it you will find a use for it eventually. with that in mind, plan as best you can without excess. then just go ahead with the launch. the journey will be long and hard. it might not even be successful. this is a reality you must accept as well. sure it sucks if you are not able to produce the software. you might get fired. but as an individual you can learn from failure. this is evolution. and if you get fired. well fuck them for not understanding that you tried your fucking best. fuck them for the fact that they did not consider the hardship they imposed on you might asking you to send a billion plus people to a far away star on a sail boat. its just not possible. but stop the anger there, because humans are strange creatures. what was hard for you will be easier for the next of us (hopefully), which is another reason to always ask for help and learn from who ever teaches you because that's what keeps you ahead and allows you to get to that far away star with a couple scraps and bruises. and unavoidable bugs. no code is perfectly perfect. neither is is perfectly useless.

so there you want quality in the process? stop and take a breather. enjoy the scenery. have a beer. sing a song. take a picture. do something else. come back fresh with a calmer mind. be attentive. take each step at a time. not everyone walks at the same pace. this is a human fact. walking faster than you naturally can introduces stress. this again is something we all know implicitly. i can not run as fast as ben johnson. but that doesnt stop me from finishing the race. besides moving at your natural pace will allow you to notice your own habits and fix your flaws before they become reborn in the code. at the very least you will not be introducing any bugs. still though, the code will have flaws of its own as it comes into contact with reality. that's another reason to build in some resilience. error checking and such. some of these things are really common sense. which is why i think that the journey analogy works better.

notice this too, everytime a building is build the construction crew goes someplace else. they got new journeys to go to. some go their seperate ways. others remain a crew. but they move on. you never see that construction crew idling at the construction site years after the tenants have moved in. that's just silly. common sense. the best weapon. etc.

i hope this helps somehow.

Alternative Analogies (none / 0) (#116)
by BrianMarick on Thu Apr 10, 2003 at 03:18:05 PM EST

There's an event at the Agile Development Conference called Analogy Fest. It's dedicated to new analogies for software.

The Analogy Fest is an attempt to manufacture serendipity, to create the circumstances in which clever people might have an "Aha!" moment.

In these sessions participants will discuss papers commissioned and collected by the session leaders. Each paper is about an analogy between software development and something completely different than software development. The analogies may be serious or fanciful. In either case, they're intended to serve as a trigger for inspiration, a way to say, "What if agile development were like X? How would we do things differently?"

The Software Construction Analogy is Broken | 117 comments (88 topical, 29 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!