The 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.) --DanielPezely ---- '''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).'' : Or, to put it simpler: it's called ''soft''ware for a reason. I don't have a problem with the HouseConstructionMetaphor, except that at some point you have to explain and convince the audience that software development is not at all like building a house: After building the house, should you decide that you want a basement, you're SOL (out of luck ;-): You'll have to pay to demolish the existing house, pay to update the design, and then pay to build an entirely new house. In an XP software project, however, it's no problem: You just "pick up the house" and "put a basement under it." Wala! It's just like there had always been a basement in the plans, and the cost is probably about the same as if the basement had always been in the plans. 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. --DanielPezely ---- 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: : Think of a house. : Consider various ways of constructing that house. : Is there a better way than conventional wisdom suggests? The standard approach attempts to make something whole: start at the bottom, work up, then finish the inside. : Give the builders authority over what they're about to create. Then give the future home-owner access to influence the house's design while it's being built. : The builder might consider the roof to be the most novel or unusual part of the house. Perhaps it's a new design unlike any other. : The roof would be selected for construction first, even before digging a hole for the foundation. : But before actually creating the roof, a test for the roof would be made. After all, the builder wants to make sure the roof will withstand the forces of nature: wind, rain, snow, ice, heat, etc. : An environment would be created for the test. It would be a facility large enough to hold the completed roof. There would be air conditioning for simulating changes in temperature. Large weights would be ready to mimic snow trapped on the roof. : Once the tests are ready, the roof can be built. It might be built in a factory where various cranes would be available. It would be free from the natural forces such as rain but exposed to our tests. : Should a problem be detected, it would be fixed long before anyone was actually living under that roof. : When the roof passes the various tests, it would be considered ready to go on the house. : Other components of the house would be constructed in similar ways. : It's all about letting those in the field make the critical decisions and getting feedback from those who must actually use it. Then there's Pairing. : Consider how a large window might be installed. : Two people are typically needed for the job. : One would hold the window as the other checks that it's level. : Then one would hold the window while the other nails it in. : The workers might trade roles throughout the day. The significance is one performs a specific task such as hammering while the other keeps an eye on the big picture such as ensuring the window is level. : The point is that two people make a more efficient team than a solitary worker. : In extreme programming this is called pair programming. These are merely for introducing the concepts. Next, we start getting into the philosophy of ExtremeProgramming. --DanielPezely ---- 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: * (PairProgramming) Why should two people share a hammer and work on the same wall? Wouldn't it be more practical to give a hammer to each carpenter, and let them work on separate walls, and help one another only when necessary? * (DoTheSimplestThingThatCouldPossiblyWork and RefactorMercilessly) You mean we should build a really cheap roof first, and then later tear the thing down and put up a slightly better roof, and then do it again, and again? * (YouArentGonnaNeedIt) But wouldn't we need to decide up front whether we want a basement or not? We can't really add a basement later, can we? * All the builders should just start working based upon what they heard the customers say, without an architect or any blueprints? I don't think the roof example you give would make sense to many non-technical people. It seems like a lot of unnecessary cost (building the roof elsewhere, testing it under conditions other than real-world conditions, then later shipping it to the site) and lack of common sense. I think this makes XP look ridiculous, and I assume that's not your intention. (And I don't mean to offend you with this characterization of what you said--it's just how I think non-technical people would see it.) 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. --DanielPezely ---- 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. ~~ WaldenMathews ----- ''[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 , and I want you to put it there , and another one there , 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:" "Poof!" I've "built" the house; it really was that easy. Here, I'll run it, to show you what it does. "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 , two , three , four , five 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. -- GarryHamilton ---- CategoryMetaphor