What Are Your Go To Software Metaphors When Working With Non-Technical Management?

Question

What software metaphors have worked best for you in discussing and explaining the complexities of software development with non-technical management?

Answer 1

I don't think you can go past the "building a house" metaphor. It's probably as close as you'll get to building software, because:

• A detailed plan is required before starting
• Some tasks cannot start until others are finished
• A screw-up in one area can manifest in many other areas
• It's hard to predict completion dates because of the two previous items
• No one wants to live in a crappy house
• Houses, like software, are typically around for a very long time and can span multiple generations, so you'd want to get things right from the start
• It's nice to change fittings, etc. to improve the look, but a complete rennovation is not so much fun
• And many more..

I'll be here all day if I keep editing this every time I think of a new example!

Answer 2

did you hire me to offer my informed opinion or be a yes man?

Communication with lesser mortals isn't my strong point but if people know that upfront they take such bluntness with the good nature it's normally intended and metaphor is normally lost on me :)

Answer 3

Not so much software development, but the research components of a software project are very much like research in other fields - Very difficult to schedule, with no guarantee of getting a useful result

Answer 4

My boss used to tell me very often that I should implement the feature X or Y as quick as possible in our application, even if it required a quick dirty piece fo code, because if I don't do it, the customer won't buy our software.

As a developer, I had a hard time struggling between what I thought was best for the company (selling copies of our app, especially for a young company) and what was best for the code quality and maintainabilty of our application.

Then, I found the term of 'technical debt' coined by Ward Cunningham : http://en.wikipedia.org/wiki/Technical_debt

It helped me a lot explaining my boss what were the consequences of a quick and dirty implementation of a specific features, while still feeling ok to do it when necessary.

Answer 5

I like the metaphor of trying to beat a rickety path to an uncertain place in a deep dark swamp that contains unknown dangers, and then building a proper road to that place.

• So first you have to decide on your target location...
• Then you need to construct a path across the swamp...
• Avoiding the quicksand and the hidden holes...
• While fighting your construction materials and the occasional swamp monster...
• To find that the original target has now moved...
• And therefore much of your effort was wasted...
• And once you decided on the new target location...
• You need to reach that location...
• And construct a highway across the swamp for the end-users to navigate...
• All of this against the clock...
• While most of the team have never seen this swamp before...
• Do I need to go on?