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:

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."

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

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

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


This article on software quality contains some discussion of why software is different from bridges, cars, etc:
	http://www.msnbc.com/news/768401.asp

See also: TheSourceCodeIsTheDesign, ProgrammingAintManufacturing, SoftwareGivesUsGodLikePowers
CategorySoftwareProduct

EditText of this page (last edited November 7, 2014) or FindPage with title or text search