Second-system effect
From Wikipedia, the free encyclopedia
In computing, the second-system effect or sometimes the second-system syndrome is the tendency to design the successor to a relatively small, elegant, and successful system as an elephantine, feature-laden monstrosity. The term was first used by Fred Brooks in his classic The Mythical Man-Month. It described the jump from a set of simple operating systems on the IBM 700/7000 series to OS/360 on the 360 series. A similar effect can also happen in an evolving system; see Brooks' law, creeping elegance, creeping featurism.
Contents |
[edit] History
Brooks noted this effect when comparing IBM's 7000-series operating system with the later 360-series operating system. It has been observed with Multics, and a large number of other significant, long-lasting software projects.
[edit] Explanation
Although expressed as a problem of software design, the second-system effect is observable throughout all human effort. It is the origin of the commonplace, "Try to do everything and you will do nothing."
Simple tasks linked to simple tasks in a way intended to bring a congruent result are more complex than the source tasks are individually.
This holds true in both a hierarchy or in an equal-peer relationship. At the very minimum, second-system effect is due to increased management efforts over the system and increased communication efforts between the parts of the system (including the manager, if one is designated). Additionally, political friction between elements, insufficiency of effort, mistiming, lack of information, and many other factors can make the bundling of tasks much more complex than the simple performance of each task on its own.
A simple example is in learning to ride a bicycle: it is not difficult to steer a similar vehicle such as a tricycle, nor is it difficult to keep the bicycle at a proper speed to keep from tipping over. However, when a learner attempts to do both he must also learn to make many split-second decisions and adjustments and usually falls off the bicycle many times before becoming proficient. The second-system effect is the additional learning that must be done before the bicyclist is properly skilled, and is additionally the extra effort required in future when riding the bicycle.
In learning to ride a bicycle, the second-system effect is minor compared with the benefits of being able to use a bicycle. In a well run automobile factory the second-system effect (and compensating for it) can continuously contribute as much as four-fifths of the costs of building an automobile: which is still far lower a cost than for a craftsman to construct a comparable automobile by himself. Second-system effect is not in itself an evil; it is a complicating factor to be reckoned into any cooperative project of worth. Like financing.
From the software standpoint, the basic impetus for second-system effect appears to be that people expect software projects to scale linearly with the number of specification items. They engage in a more complex project of the same general type by enlarging its specification, with no care paid to the time to completion of the project.
Unless carefully designed, the specification items can interact, causing a rapid growth in the combinatorial complexity of the final system. This causes a large number of possible failure modes, which are difficult to locate, test, and repair.
[edit] A possible solution
One general solution may be to limit the forms of interaction between the parts of a new software system to one or a few stereotyped communication methods.
For example, Unix has developed many software utilities that interact via an intentionally simple byte-based file system, and this set of utilities is one of the most reliable large-scale software systems known.
Building directly on this interpretation of this experience, the Plan 9 and Inferno operating systems let programs interact only through files, and these operating systems generally have been reported to be both robust and flexible.
This principle also seems to explain much of the success of relational databases, and object request broker architectures, such as CORBA, which provide a similar standard coordinating method.
[edit] Popular culture
Examples of the second system effect can also be seen in various forms of entertainment [citation needed], most notably movies and music, where the sophomore slump is common. The equivalent to the "second-system effect" in a movie or TV series could include special effects or new, elaborate, or "shocking" plots [citation needed]. See Jumping the Shark.
Sequels to successful movies or albums are generally less successful than their predecessors for a number of reasons. First, the creators have often already used their best ideas the first time out and thus tend to desperately throw everything they can think of into the successor, in the hope that quantity can be substituted for quality, usually to disastrous effect. The creators may "buy their own hype" and overestimate their own abilities. Finally, many artists' breakthrough works are actually developed in relative obscurity at a leisurely pace during a process of dues-paying, while second works tend to be developed on tighter deadlines that do not allow much reflection. [citation needed]
[edit] See also
- The Mythical Man-Month
- Unix philosophy
- Creeping featurism
- Zawinski's Law of Software Envelopment
- OS/2
- software bloat
This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.