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
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
that software development is more similar to the
practice of craftsmanship and less like the practice of engineering.
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:
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:
See also: TheSourceCodeIsTheDesign