House Construction Metaphor
House Construction MetaphorThe issue is this-- How do we explain ExtremeProgramming to a non-technical audience. (See MetaphorsForNontechnicalAudience for a list that is hopefully growing.)
The average person needs a starting point rooted in the world around them. It must be completely void of software terminology.
A straight-forward starting point is something most people in the world understand: a house. This metaphor has value in that it can be visualized. (For a DocumentaryFilm such as XpDocumentary, it would be demonstrated via animation.)
Discussion moved from XpDocumentary:
Why the HouseConstructionMetaphor?
Regarding MetaphorsForNontechnicalAudience, most people understand "house." Many also grasp the crudest elements of construction thanks to shows like ThisOldHouse?. It's a starting point for effective communication. We build upon something they comprehend then move towards the more abstract concepts.
For those who have seen http://c2.com/ppr/about/author/kent.html or read TheTimelessWayOfBuilding to which he refers, this is an appropriate starting point. -- DanielPezely
I think the HouseConstructionMetaphor is totally inappropriate in connection with XP. The Construction metaphor was what brought us from Chaos to the WaterfallModel, which was a good thing... thirty years ago. SoftwareDevelopment is clearly unlike construction, especially ObjectOrientedSoftwareDevelopment?. In the CooperVsBeck article, Kent supports this view. TheTimelessWayOfBuilding gave us patterns, but that shouldn't tie us to a HouseConstructionMetaphor. How do you ReFactor a house? SoftwareIsNotConstruction? in the same way the SoftwareIsNotManufacturing. -- RobHarwood
It's possible to refactor an indoor pool into a steel floor. By yourself. Done it. Don't have any friends (who would presumably help).
Maybe we need HouseConstructionMetaphor to describe traditional non-refactoring implementation, and HouseConstructionMetaphor+TimeTravelMetaphor? to describe XP. ;-> -- JeffGrigg
From page 4 of the CooperVsBeck article:
Cooper: [...] Building software isn't like slapping a shack together; it's more like building a 50-story office building or a giant dam.
Beck: I think it's nothing like those. If you build a skyscraper 50 stories high, you can't decide at that point, oh, we need another 50 stories and go jack it all up and put in a bigger foundation.
Cooper: That's precisely my point.
Beck: But in the software world, that's daily business.
I agree that in a software context, the HouseConstructionMetaphor has major problems. Please remember, this is about getting non-technical people to understand.
And as JeffGrigg suggests, the metaphor will be dropped once that connection has been established.
Please see MetaphorsForNontechnicalAudience.
Likewise, software developers indoctrinated in other methodologies may need an unrelated example before they can shift perspectives.
Compare this to the inventor of the minicomputer. He was considered a genius for making the mini yet an idiot for dismissing the PC. I believe he was just too close to the subject to be objective enough to let go of his earlier ways.
While a metaphor of house construction may send shivers up the spine of any long-time ExtremeProgramming advocate, there is still value in it. Keep in mind CooperVsBeck (article, page 4) is a debate between two software people.
The metaphor for non-technical people would work like this:
Next, we start getting into the philosophy of ExtremeProgramming.
I agree that finding a real-world metaphor is important, but I think this particular one has some problems in regard to explaining XP. House construction has a lot of physical constraints that are at odds with the fluidity of software. Construction is better suited to the WaterFall model, because change to the design after building has begun really does have enormous costs associated with it.
When you use this metaphor in relation to XP, I think non-technical people would have these questions:
I'm not sure what a better metaphor is. Something where change is relatively inexpensive, and where you don't know exactly what you want to end up with when you start. Maybe creating an encyclopedia--each article is written independently, each article is reviewed while it is being written, and you rewrite the articles or re-organize the information as you go along to make the encyclopedia better. Or maybe gardening.
-- KrisJohnson
Ah, I understand! I agree with you.
The house metaphor is too problematic. I was perceiving it differently, but your point is well taken that people would get lost. And the whole point of a DocumentaryFilm is to help people understand.
I like your suggestions and will explore those next. See MetaphorsForNontechnicalAudience.
It is true that the HouseConstructionMetaphor is important when presenting the history of software up to XP and AgileProcesses. I would see value to a non-technical audience in saying, "For years, many people have believed developing software is like house construction. This has lead to a lot of confusion and wasted money, because when it comes right down to it, software is very very different than construction." In other words, "You may think it's like house construction. Stop thinking that!" -- RobHarwood
Last week, I spent a day in my basement "refactoring" the electrical wiring. I needed to insulate between joists for radiant heat, but there was so much wiring in the way I instead focused on cleaning it up. I pruned dead material. I rerouted for more direct routes. I rerouted to get 120v ac away from cat5. I added some, but mostly took away. No new functionality. Then I insulated.
Several weeks ago, my carpenter and I started on a rear porch for my addition. The architect's drawings did not cover this (a change in design). We began trying to anticipate things like where will the roof intersect the wall above, what are the roof pitches, how will the trim join with existing trim, where will floor level fall in relation to indoors, etc., etc. Too many details and no inclination to sit down and draw it all, so we began laying it out on the house. Then we built it. Then we discovered the roof was three inches too high to match the frieze board, so we lowered it as a unit (using car jacks). Now we've discovered the deck is too high also, so we'll lower that in similar fashion. These are not typical house construction tasks, but they have some of the flavor of software development, in the sense that we built the porch as its own prototype in order to learn enough to build it right. Fortunately, that didn't force us to knock everything down and start over. Many building tasks, as it turns out, are indeed incremental if you're smart (and dumb enough, to be honest) to approach them like that.
Perhaps when they say "house construction" most folks think of building a new house from the foundation up. Funny, when thinking wholesale software methodology, many methodologists make this same leap, leaving us models that address starting from scratch, but ignore maintenance and enhancement altogether. In house construction, we have the analog to software maintenance in the areas of renovations, additions and restorations. The people who do this work have to think on their feet, and have to be willing to ditch one idea when it costs too much in the interface with another trade. Adaptive thinking is by no means unique to software development.
Moreover, how many people who have contributed ideas to this page are sufficiently experienced in house construction to make the analogy?
Finally, regarding what is the software and what is the design and what is the house. If you assert that the code is the design and the running system is the software, then I assert that the studs and walls and foundation are the design and my family moving about inside is the house. The use of the thing is not the thing. Software is soft because you don't have to bend steel or shave wood to change it, not because its execution is mere voltage difference.
[I've been processing this idea on a background thread, and came back to revisit it.]
"We have always thought about software development as if it were like constructing a house: It's easy to change the design at the beginning, but changes become harder and more expensive as you actually build the house.
"Let's say you asked for someone to build you a house with the bedrooms on the left and the living room on the right, but later changed your mind and now want the bedrooms on the right and the living room on the left. If you change the plan in the blueprints, before the house is built, is probably not such a big deal -- just flip the blueprint over and have it redrawn. But if you change your mind after the foundation is laid, or the walls are put up, or after the entire house is finished, the change becomes dramatically more expensive.
"So, in building houses and software, we have always started by gathering the requirements from the new owners, and drawing pictures to illustrate what things will be like. We review and update these blueprints or 'design documents' and insist that the new owners sign them as part of a contractual agreements as to what will be delivered. We do this because we know that changes to the blueprints or 'design documents' done later, after much construction has been done, will be expensive, very expensive.
"But then we had an epiphany: "Software development isn't at all like building a house!" The "computer programs" we work with at not at all like houses all lined up in a row, our programs are the DESIGN for the houses. We realized that the "construction" of a working program from a "source design" is so quick and easy as to be essentially free. It's as if you could magically construct a house for free, once you had finished detailed blueprints. Copying software programs is also so easy as to be essentially free. It's as if you could build a tract of houses by pointing at the first finished house and then saying "I want another one just like that one there <point>, and I want you to put it there <point>, and another one there <point>, and so on." Each time, "poof!" the houses just appear where you were pointing.
"Here, let me illustrate: Here's the source code of a program. Its "design" or "blue print for building the house" as you will. Watch me while I "build the house:" <Types "make" and presses Enter.> "Poof!" I've "built" the house; it really was that easy. Here, I'll run it, to show you what it does. <Brief and meaningless colorful program gets run.>
"Now I'm sure that all my friends would also like to have this, so I'll "build" them houses, just like this one: Lets see, I want one <Ctrl+C>, two <Ctrl+V>, three <Ctrl+V>, four <Ctrl+V>, five <Ctrl+V> houses. See how easy that was? (Well, I'd still have to copy them to floppies, CDs or send email for this really to work, but it's clearly a lot easier than building a tract of houses.)
"So we realized that software development isn't at all like building a house. It's more like making a design or blueprint for a house, and then having some magic way to make the house "poof!" appear, just exactly as the blueprints describe it.
"So maybe we should build software in a way that's different from building houses. It's not expensive to "add a basement" or "flip the floor plan over" after the software is built, in fact it can be and should be very easy.
[And there's a lot more that can be said at this point. ;-> ]
[Story started by JeffGrigg. Please feel free to append and refactor as inspiration drives you.]
I'm inclined to vote with the "it's more like house design than house construction" idea, but I have a few thoughts. I worked one summer with a guy who was a surveyor, an architect, and a builder. He built scale models before he ever laid a brick.
Once software is in production, then changing it can be very much like trying to modify a house that's already built. I have used this metaphor to convey to decision makers the concept of SoftwareInertia?. After a certain point software seems to calcify into something brittle that confounds all attempts to modify it. Current work (firmware a decade old) exhibits this phenomenon.
Modeling provides a middle ground. You do your blueprints and drawings (elevations) of the structure until you get to a certain point, then you build a scale model. Once rendered in actual 3d, things show up that get missed in the drawings. CAD can help here, but there's really no substitute for modeling.
With software, the modeling is done differently, but by exposing the user to test modules before you've "dug the foundation and laid the damned plumbing" you can catch many "oops, the bathroom really belongs there" things.
Since I'm not a practitioner of nor expert in XP, I lack the terminology for this example, but the software equivalent of scale modeling is part of the answer to the (completely non-viable) business of modifying the design of a house while it's being built.
EditText of this page
(last edited September 16, 2010)
or FindPage with title or text search