Red Squirrel Reflections Dave Hoover explores the psychology of software development

[Previous entry: "Impressive Glue"] [Main Index] [Next entry: "Another Elephant Hoister"]

Mind Your Metaphor (revisited)
Monday, March 1, 2004

I am currently working through the Poppendiecks' excellent book and found a few ideas that made me think back to an earlier entry on metaphors in software development.

"Perhaps some of the reluctance to use approaches from product development comes from unfortunate uses of metaphors in the past. Software development has tried to model its practices after manufacturing and civil engineering, with decidedly mixed results. This has been due in part to a naive understanding of the true nature of these disciplines and a failure to recognize the limits of the metaphor." (xxii)

"Principles are guiding ideas and insights about a discipline, while practices are what you actually do to carry out principles. ... We believe that there is no such thing as a 'best' practice; practices must take context into account. In fact, the problems that arise when applying metaphors from other disciplines to software development are often the result of trying to transfer the practices rather than the principles of the other discipline." (xxiv)

Today I was skimming some books in a nearby Borders during lunch. I picked up The Art of Software Architecture and read an interesting sidebar on metaphors. Albin disparaged the common assumption that software architects should resemble building architects. To paraphrase Albin, if designing, constructing, and maintaining buildings was like software development, building architects would be getting requests to have entire floors removed or added and additional structures appended onto the building.

The sidebar went on to note that urban engineering might be a better metaphor for software development, where engineers and planners receive requests for new housing developments, reducing traffic congestion, and connecting adjacent communities. Like any metaphor, Albin notes, this one also has limitations, but it certainly feels more applicable to me.

In the short term, though, the urban engineering metaphor does almost nothing for me because I don't know jack squat about urban engineering. Therefore, my application of this metaphor would almost certainly be naive. I believe this is what makes the Poppendiecks' book so effective. They have expertise in the domains of lean development and software development. Thus, Lean Software Development.

The Poppendiecks' book encourages me to continue to explore the potential metaphors and shared principles between the two domains in which I have expertise: family therapy and software development.

Replies: 1 Comment

Thanks for the addition to my page:
http://www.clabs.org/blogki/blogki.cgi?page=/ComputersAndTechnology/ConstructionAnalogy

Posted by Chris Morris on 03/03/2004

Powered by Greymatter