Second-system effect

From Wikipedia, the free encyclopedia

In computing, the second-system effect or sometimes the second-system syndrome is a form of sophomore slump of which the tendency is 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.

1 History
2 Explanation
3 A possible solution
4 See also

[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 design effort. It is similar to (but not exactly the same as) the commonplace "fighting the last [previous] battle."

People who have designed something only once before try to do all the things they "didn't get to do last time," loading the project up with all the things they put off while making version one, even if most of them should be put off in version two as well.

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