Metaphors For Nontechnical Audience

For presenting ExtremeProgramming to a non-technical audience, metaphor is useful.

While many software people and philosophers may dislike the use of metaphor, please understand it's a useful tool for others. It's about establishing a starting point for communication. It's building on a common language.

Metaphor is especially useful for the XpDocumentary.

-- DanielPezely

Personally, I've found the nontechnical crowd detest it when technical people use metaphors to talk to them. The problem is that the metaphor loses too much information; it conveys nothing. -- DanielKnapp

I'd agree that it shouldn't be dumbed-down too much, and the entire documentary should not be centered upon one metaphor. But if the intended audience knows absolutely nothing about what programmers do, comparisons with familiar occupations may help. -- KrisJohnson

True. I once told a friend who believed that "all programmers do is type a lot" that "all architects do is draw pictures". I think that was an effective way of making the point. However, I would never have attempted to extend the metaphor. (If it had been anyone but a friend, I probably would have just walked away from the conversation, actually...) -- DK

Metaphors for a non-technical audience:

JazzMusicMetaphor: Consider how classical versus jazz music comes to be. TomStambaugh gave a wonderful description for the XpDocumentary.
HouseConstructionMetaphor: Since the house metaphor breaks down within the scope of xp, that becomes the turning point for discussion. That leads to introducing ExtremeProgramming as something unique. See the chapter TaoOfExtremeProgramming in the book ExtremeProgrammingExamined, where PeterMerel compares a BigDesignUpFront effort to a house designed incrementally.
CreatingAnEncyclopediaMetaphor: Suggested by KrisJohnson from HouseConstructionMetaphor debate. What comes to mind?
CategoryGardeningMetaphor: Suggested by KrisJohnson from HouseConstructionMetaphor debate. What comes to mind?
ArmCl: When FrankStone's done with you, he'll turn your software into hardware.
FurnitureArrangement?: Constraints are the size of the room and where the doors/windows are. Existing furniture represent requirements. Pieces need to be positioned for good flow and pleasing appearance; new pieces need to be bought/made to fill in the gaps or add seating for more people.

My vote is for the JazzMusicMetaphor, which TomStambaugh describes on XpDocumentary. -- RobHarwood

Note also that, within XP, the practice SystemMetaphor is itself a metaphor that each team designs to present their project's architecture (in very rough terms) to a non-technical audience. It therefor also provides a framework for all the technical jargon and program identifiers the team will then generate.

Consider this: XP works because software development is fundamentally a design activity, not a construction activity.

Once the software is "designed," which means that the source code has been written, the "construction" of object code by compiling source into object is so quick, cheap and easy as to be essentially free. The other aspect of "construction" - "mass production" of copies so that you can give the product to lots of people is also remarkably cheap: Copying software is easy.

So, writing software is much more like designing a house than building a house.

("Big design up front," by contrast, makes a lot of sense if you assume that writing software is just like a construction activity.) -- JeffGrigg

This may be a bit off the wall, but how about ComedyWritingMetaphor?? A lot of comedy acts and TV shows are (or were) written by groups of people, who often paired off. One person might come up with a good joke, and another would make it better or come up with another joke that played off the first one. Bad jokes got cut. All these jokes and gags are woven together into an "act" or a "show", which might be performed and refined night after night.

This also reflects the creative/imaginitive aspect of programming. And "brevity is the soul of wit" would fit in with DTSTTCPW and other "keep it simple" aspects of XP.

The downside would be that a non-technical audience might take this to mean that XP is not for "serious work". (I think the JazzMetaphor? may suffer the same problem.)

Comedy writing wouldn't be great as a single metaphor for XP, but if you are using lots of metaphors as examples, this one might fit in. And it gives you a chance to lighten up the documentary with some totally off-topic jokes, to keep the non-techie audience from getting too bored with all this geeky nonsense.

-- KrisJohnson

How about a business metaphor? It has the added advantage that it isn't a metaphor, but reality.

XP is risk averse. It avoids making decisions until either you have to make them, or you have enough information to make the right one.
XP works with the real world, which is constantly changing.
XP "reengineers" the system.
XP follows TotalQualityManagement with UnitTests, AcceptanceTests.
XP is customer first. (OnsiteCustomer, etc.)
XP is shareholder first. (i.e. more customer stuff)
XP measures time in "quarters", except they are shorter than three months. This includes planning out the next quarter, as well as reporting on the previous quarter complete with measurements (i.e. the Velocity).

I'm sure you could go further. Plus, I think I'd die in fits of laughter if you tried to justify one methodology with one from another domain. ;) -- SunirShah

That doesn't sound so much like a metaphor as it does MarketingHype?.

This is somehow different from the rest of XP flak? I say if the XpDocumentary is meant for the cool kids, we should talk to them in their crazy moon language.

I Second. This kind of blabla is just what non-techies are used to hearing and doing. So they should understand it. (You probably have to explain Metaphor != realThing a couple of times)

As a pseudo-nontechnical guy (I'm not a professional programmer) each principle of xP is very digestible by itself. What I dig about xP is the persistent and elegant engineering out of stumbling blocks:

Studies have shown that code review works - how can we make sure that code review happens all the time? Instead of instituting a comprehensive code review process/policy (that won't be followed anyway), we just make everyone program in pairs.
Long meetings kill productivity - how can we make sure that meetings are short? Everybody stand through the entire meeting.
Hard to understand client's requirements? - how can we make sure that the client gets what she wants? Instead of instituting a comprehensive requirements analysis (that won't be read anyway), we just bring the client on-site, she's always available.

Sooner or later the "AhaMoment" will hit. -- SeanOleary

A metaphor that appears in KentBeck's books is that of driving. One does not drive by pointing the car at the destination and then driving straight ahead - one constantly makes little corrections. You drift a little one way; you steer a little the other way. You don't plan every curve in the road, but you do have some idea of which roads to take. See DrivingMetaphor.

JimHighsmith uses 'fixing your position' from sailing before GPS. Navigators used to make rough estimations all the time, but would do more detailed estimations every dawn and dusk by checking the stars, etc. This metaphor works mostly for project planning, whereas Kent's extends a little further with PairProgramming. I think for a non-technical audience, fixing position makes more sense for a planning activity. For a technical audience, I think the driving one works better. Could be wrong.

More about sailing that might make it a useful metaphor:

When the wind shifts, you have to adapt your plans accordingly. There's no point arguing about it.
The crew is constantly monitoring and making little adjustments to the sails.
You can't always trust the map or the weather reports. You have to pay attention to what you see, not what you were told you were supposed to see.
You really have no idea exactly how long it is going to take to get anywhere. (But you'll have fun anyway.)
You can speed up by throwing big heavy things overboard.