Fog Creek Software
Discussion Board




Software Development Analogs

I've frequently heard software development compared to the construction industry.  There seem to be some similarities, but there are enough differences that I think this is a poor analogy.  I've also heard software compared to the publishing industry, though this one fails even more in my thinking.  Anyone have better ones?

My personal favorite is building software is like making a movie.  Both produce what are essentially made-to-order, one shot products.  Both try to use a lot of up front, low cost prototyping to ensure the correctness of the more expensive downstream products.  Both have complicated schedules that are typically very sensitive to a small number of critical resources.  Both can require quite a bit of rework before the product is finished, and it's difficult to tell when you have the product "just right" before it hits the marketplace.  Actors are like coders, directors are like project managers, writers are like architects, etc.

What's your favorite and why?

nuttin' to read
Wednesday, March 05, 2003

The movie analogy is really good! Though one drawback to using it is not everyone is familiar with how movies are made. I'd think the average person is more familiar with construction then movie making.

Jeff

Jeff
Wednesday, March 05, 2003

I was serving printers and plotter at one of the Design Offices (you know, AutoCAD and all that engineer stuff). Device development is like software development, just compilings and buildings were made rarely -- monthly maybe

:)

Yuri
Thursday, March 06, 2003

There is one notable problem with the movie analogy...

Once the movie is made, it's over, OVER. It's out
to the cinemas and DVD's and the crew start working on completely different things. There is no support, no maintenance (which is one of the most important parts of a software engineer's work and considerations), no "this will be fixed with a patch in version 1.0.4.221".

While writing software, one must pay careful attention to being able to maintain it later. Movies is not so... this clever hack makes it possible to make this scene - cool, don't think about maintaining it later.

Why does software engineering needs analogies at all :-) ?

Anon
Thursday, March 06, 2003

How about this, the software industry is like the (drum roll....) software industry. We have some similiarities with a lot of industries, but we are not construction or movies or basket weaving, we are our own thing.

Comparisons are often dangerous. For instance, if you let the business side think that software is like construction.. you get ... "oh yeah well just slap it together outa prefabs" (standard components) on the surface OOP does look like that. But in OOP unlike construction, you dont have to shape every single brick to make it fit in with the other bricks.

Daniel Shchyokin
Thursday, March 06, 2003

Well, anon, you got me there.  The analogy does indeed break down when it comes to maintenance.  But who says analogies need to be all encompassing?  Do you have any that fit a specific part of the job?

The main reason I was interested in analogies is that it's interesting to hear about how other things get accomplished.  It's also useful to take methods from more mature disciplines and apply them to your work.  Obviously, if you do this brainlessly you can shoot yourself in the foot.  Seems like it might make sense, though, so see how scheduling is handled in movies.  If they can do it successfully, maybe you can apply something they are doing to your work and make your scheduling a little simpler.  Maybe we could learn something about quality control by studying their editing process.  Who knows until you take a look at it?

I'm personally not one to try to simplify my discussions with management by drawing an analogy to something ostensibly more familiar.  As you guys have said, that's dangerous because folks will take the analogy way past where the similarity stops, if it benefits them. 

I do, however, try to use very basic, focused analogies to illustrate a point, and occasionally to rile people up.  For instance, one I like to use is to compare the estimation process to buying a car.  Asking me for an estimate early in the project is like me asking you how much it will cost to buy a car.  Neither one of us can give an good answer without more information.  I need to know things like how many people will use this thing at one time and you need to know whether I want laser weapons or ejector seats.  Now, if you force me to promise you a number this early, that's the same as me telling you I want a firm number for the price of the car and you have to pick up the difference if your number comes up short.  Just like you are going to quote me some outrageously high number for the price of the car, I am going to quote you an outrageously long project duration.  We're both going to cover our rumps.  I am willing to say, though, that I'm 90% sure that it will take at least a month but not longer than a year, same as you are probably willing to tell me I'll spend at least $5000 but not more than $250,000.

This doesn't always work, but it is a fun game to play. It's especially nice because I've already though through all the directions the dialog might go, but they get caught by surprise.  Puts them on the defensive for a change. On the occasions when it does work, it's priceless.  Until they go meet with their manager and try to convince her...

nuttin' to read
Thursday, March 06, 2003

Why do we need analogies at all ?

Eli Bendersky
Thursday, March 06, 2003

I totally agree with Eli. Why the need for analogies..

Reminds me of the old addage.

Understanding binanary counting:: There are 10 kinds of people. Those who do and those who don't.

tapiwa
Thursday, March 06, 2003

We don't need them.  They are useful, to me at least, for reasons I mentioned earlier (unless the post has been deleted and I am the only one still seeing it :P).  Let me turn the question around, "What's wrong with having them?"

The benefits are clear to me, what are the costs?

nuttin' to read
Thursday, March 06, 2003

I agree with Eli as well, we dont need them when talking to eachother within the devleoper community.

However we need them when talking to customers. I remember talking to a plumber once, who was kindof upset that the "tech guys" at the company he worked for took forever to deliver whatever it was they were delivering.

Longtime Joel readers may remember the "Iceberg secret" essay that basically said that people doesnt know that 90% of the work in programming is "invisible" to the user. To get this point across I found that analogies that translate into the customers world may be nessecary.

If only to shed light on serialization problems in software development, or ever-changing specs, you have to find out the the plumbing guys and the aircondition guys and the carpenters cant all be working in the same place at the same time, or that changing of the blueprints every other day results in delays. The latter is obvious to anybody working as a plumber, however the term "serialization problems" might not be.

Patrik
Thursday, March 06, 2003

Another problem with conveying the general nature of SW development to 'outsiders' and customers can be the imcomprehension of the people you're dealing with.

Perhaps they've never had to build or "make" ANYTHING in their lives because they've always been in the executive, business administration, or sales areas. And I'm singling out those three areas as bastions of stupidity. These kinds of people expect to click their fingers and see something. So an analogy may not cross this divide. Or worse, the imperfect nature of the analogy may give the 'outsider' argument points against you because they don't understand that it's just an analogy.

Years ago I worked for a small hack shop that was developing a real estate specific package.  My boss had talked to realtors in pitching the product and he was QUITE emphatic that the realtors would not understand that development could take time.

Basically, he said that if he told them about a new development we were proposing, they would ask at that time if they could have it to try. They would not believe that implementation existed, that it took time-effort-work to create a new feature.

Because they were realtors, most of them (expecially the owner of a real estate firm) had a case of the profound stupids. If anything, they saw software like french fries at McDonald's. IE: get on that deep fryer and whip up a batch, why should it take any time, it's just a bunch of typing, right?

Bored Bystander
Thursday, March 06, 2003

One plus to analogies:

No girlfriend that I've ever had has understood what I do.

Maybe it's a function of where I live (midwest U.S.), but everyone around here stares blankly when I tell them I'm a Software Engineer.  So then I usually just say "Programmer," which is slightly better for them.  I've had many people ask me how I can type in 1's and 0's all day.  I'll have to try out the movie analogy.

Plus, it would probably add a certain edge in picking up women if I said "I'm an actor." :)

Dignified
Thursday, March 06, 2003

Well I think analogies are very useful. I've done a lot of animation over the years, and it is very similar to the software process. With a series you also have the maintenance issues, and things like translations, drifitng specs, an evolving product, generated vs handmade, in house vs outsourcing, egos and talents etc etc. The interesting thing is animation uses a very different process to solve very similar problems. It is also a lot more quantified and mature (and older) process than software uses. Software is still pretty much at the stage of debating whether it is better to have a plan or not, never mind a proven methodolgy of implementing it.

In animation (and movies) you don't have the luxury of keeping your key teams small to reduce points of communication, so you need a good system. You also have a larger number of people that aren't that interested in or capable of managing complexity, which means you generally have a more methodical system for doing that too. There is a lot to learn there. I really don't think the answer is keeping your team down to 5 or less like everyone making software seems to think is a reasonable restriction.

Robin Debreuil
Thursday, March 06, 2003

I think the analogy to movies should be heavily promoted. I want a salary like Tom Hanks'  :)

sgf
Thursday, March 06, 2003

I dunno..

Maintenance = Sequels.. It could work.

Lee
Thursday, March 06, 2003

Further problems with the software-moviemaking analogy: there is absolutely no similarity of the compensation scale and method, nor the treatment, for actors vs. programmers.

All programmers are schmucks deserving no dignity in the eyes of management while some actors are 'stars' deserving utmost respect and high maintenance. Yeah, right, I'll ask for a fruit basket next time in go into my client. :-)

(I read somewhere that an ex publicist is trying  to start a 'talent agency' for IT people, to reward 'star performers'. He needs to put down that crack pipe.)

Most actors are free agents. Most business *DESPISES* IT contractors (free agents) with passion.

Many actors get paid royalties for performances of their movies. Programmers are often scammed out of fair market pay with promises of royalties that conveniently never  seem to be due. (asking a programmer to forfeit pay in exchange for "paper" is the oldest trick in the book, I've been asked many times to do this.)

Actors are paid on a contract basis, with steep penalties for reneging on the deal. Most programmers are wage slaves and can be dismissed at will, even after they complete the goal.
Actors are publicly credited. Programmers are usually not, unless they own the company.One definite similarity between programmers and actors: youth, beauty, and compliance with fads and fashions definitely account for 99% of the hiring decisions.

Bored Bystander
Thursday, March 06, 2003


Farming?

Football?

Want more examples?  Read "Code Complete" by Steve McConnell ... or "PeopleWare"

regards,

Matt H.
Thursday, March 06, 2003

Most of the people who work on a movie are not actors.

And judging by the people I know who work up here in "Hollywood North" (Toronto) they are not paid as much as Tom Hanks.

Furthermore, most actors are not paid as much as Tom Hanks. In fact, the average and mean actor's annual incomes are pitiful.

I'm very glad I don't work in the Movie Business!

--
http://www.braithwaite-lee.com/

Reginald Braithwaite-Lee
Thursday, March 06, 2003

I've always thought analogy was one of the worst forms of supporting an argument (not that that has anything to do with this particular thread).  They're easy to twist in any way you want and don't deal directly with facts.  If someone begins an argument with an analogy I know their point is pretty weak.

chris
Thursday, March 06, 2003

Chris:

Using an analogy as support for an argument may be an indicator of weakness, but an analogy can be good for explaining the argument.

Consider here: customer wonders why it's so expensive/time-consuming/whatever, and you can tell them real arguments (well, the new FOOBAR APIs are hard to use, or why my favorite acronym has bugs in it), or you can tell them things that the PHB will understand (How long did it take to build your house?).

Mike Swieton
Thursday, March 06, 2003

I wouldn't use analogies as a kind of pseudo-proof of an argument, but they are really good for trying to generate insight.

nuttin' to read
Thursday, March 06, 2003

The analogy I use to explain people is: The PC is pretty dumb. It's a pupil and I'm a teacher. =)

sgf
Thursday, March 06, 2003

Analogies are most useful when you use them to see how other fields solve similar problems. A tv/animation series certainly is akin to maintenance - a poorly designed anything will become a giant pain and will be very hard to change by episode 3. And if anyone thinks star programmers aren't pampered or compensated generously, umm...

Robin Debreuil
Friday, March 07, 2003

One thing that can be useful from the movies analogy is the distintion between pre-production and production.

In the movies this distinction is useful, because once shooting begins, the meter is running. So you'd beter be prepared and not be wasting time on decisions that could have been made before the crew was ready and all geard up.

Product development (not just software) can benefit from a similar phasing and can learn a lot from the techniques that are used in pre-production to keep costs to a minimum, while eliminating risk to a maximum.

Until today, too little is being done to even recognise, let alone exercise, this in product development. Not withstanding requirements management, iterative and incremental development, up-front design, et cetera.

Practical Geezer
Friday, March 07, 2003

*  Recent Topics

*  Fog Creek Home