Software Is Different

Many people espouse the view that the design and construction of software systems is in some way different from the design and construction of more traditional "created" objects (ex. bridges, cars, houses, etc.). Others take the opposite perspective and argue that many (all?) of the problems with software (bugs, etc.) stem from the fact that "sound engineering practices" aren't used when developing software (ex. CMM).

In many situations, this discussion devolves into a geek version of the "tastes great! - less filling!" beer commercials, with not much in the way of resolution developing. There are also considerable number of articles, talks, and books out there describing why the author feels strongly about one perspective or the other, but very few which attempt to assemble, compare, contrast, and discuss the various specific differences and similarities between software development and the design/manufacture of more tradional objects.

It's my hope that the format of this forum will present the opportunity for such a discussion to occur. - GeoffSobering

Topic 1) Software is different because the manufacturing process is trivial compared with conventional assembly lines.

Is this a red-herring? Perhaps the comparison between a Detroit assembly line and an automated CD-Burner isn't useful in this discussion? Are there perhaps similarities in the design process for cars and software that don't depend on the differences between the actual manufacturing technology?

Actually, to try to explain the difference between software design processes and traditional object design processes, the comparison should be between the design and testing of physical objects and the design and testing of software objects. I.e., how do you get to the first copy of (the final version of) each?

Comparing the manufacturing processes (and material costs) can be used to explore another aspect of why software is different: the fact that the second copy of a piece of software costs nearly nothing leads to many interesting economic consequences (e.g. software pirating, free software, etc).

Topic 2) Standard engineering practices aren't applicable to software development because software is different.

This is a often discussed point. For example, PeteMcBreen argues at length in his book SoftwareCraftsmanship that software development is more similar to the practice of craftsmanship and less like the practice of engineering.

You can run software projects the same way as "standard" engineering projects -- both have options along the continuum from BDUF to trial-and-error. It's the economics of those projects that make the difference:

"Standard" engineering deals with projects where a design-build-test cycle has significant monetary and time costs (e.g. $1,000,000 and 6 months per cycle). Trial-and-error on such a project would be horrendously expensive and slow, so the most economical process is closer to BDUF.

What if you had an environment where:

a design-build-test cycle can be made by one or two people, in a matter of minutes, with essentially no material cost (TestDrivenDevelopment)
you can feasibly keep a huge number of trials very cheaply, along with records of their successes (ExtremeVersionControl)

Then, a heuristically-guided incremental-improvement-by-trial-and-error process would be economically attractive.

To generalize: the more expensive it is to design, build, and test your product, the closer your process should be to BDUF. The less expensive it is, the closer your process should be to trial-and-error.

The "League for Programming Freedom"s perspective:

http://lpf.ai.mit.edu/Patents/AgainstSP/asp-05.html

This is a pretty good statement of the commonly accepted viewpoint that software and other design-endeavors (ex. a car) are very different.

There are real inaccuracies in this article.

"For example, a program of 100,000 components might be 50,000 lines long and could be written by two good programmers in a year."

Try 50K components will be at least 100K long.

"The total investment would be less than a $100,000."

Only if one of the programmer you hire is making 1/3 the salary of the other- not bloody likely.

" By contrast, a computer program is built out of ideal mathematical objects whose behavior is defined, not modeled approximately, by abstract rules."

This is a misleading statement of enormous scale...

"The program with 100,000 parts is as complex as an automobile, though far easier to design."

That depends, doesn't it? You see what I mean about this article? It really is hoping to make points about patents- its errors make it less useful in the current discussion.

This article on software quality contains some discussion of why software is different from bridges, cars, etc:

http://www.msnbc.com/news/768401.asp

CategorySoftwareProduct