dalamb@umiacs.umd.edu (David Lamb) (02/22/91)
In "The Mythical Man-Month", Fred Brooks (1975) described the "second system effect": on one's second try at a particular kind of system, one tends to add all kinds of bells, whistles, kazoos, etc., vastly overcomplicating the software. When I first read it, this seemed like it had to be true, but I haven't seen anyone else discussing it. Does anyone else have any published references discussing such an effect? Do y'all believe it's still a problem these days? -- David Alex Lamb internet: dalamb@umiacs.umd.edu
pat@megatest.UUCP (Patrick Powers) (02/22/91)
In twelve years in the biz I haven't observed a second system effect. CM Hoare though is a believer. See his Turing award lecture, printed in CACM 1981 or thereabouts, in which he relates the tale of his second system, recalls the development of the Algol standard, and castigates Ada(Tm). -- --
jerry@TALOS.UUCP (Jerry Gitomer) (02/23/91)
dalamb@umiacs.umd.edu (David Lamb) writes:
:In "The Mythical Man-Month", Fred Brooks (1975) described the "second system
:effect": on one's second try at a particular kind of system, one tends
:to add all kinds of bells, whistles, kazoos, etc., vastly
:overcomplicating the software. When I first read it, this seemed like
:it had to be true, but I haven't seen anyone else discussing it. Does
:anyone else have any published references discussing such an effect?
:Do y'all believe it's still a problem these days?
I haven't seen anything about this, but if the commercial
software packages being offered in the PC-DOS world are typical
the problem still exists. My evidence is the ever increasing
size of each subsequent release of the typical package.
Another indication of the continued existence of the problem is
the evolution in products, such as computer languages, which are
subject to standards. I don't know about you, but I can't think
of any example in which a revised standard has resulted in a
significant reduction in language size or complexity. (To the
best of my recollection every standard revision has resulted in
the language getting bigger and more complex.
--
Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA
I am apolitical, have no resources, and speak only for myself.
Ma Bell (703)683-9090 (UUCP: ...{uupsi,vrdxhq}!pbs!npri6!jerry nobody@blia.sharebase.com (Nobody at all) (02/23/91)
> From: dalamb@umiacs.umd.edu (David Lamb) > > In "The Mythical Man-Month", Fred Brooks (1975) described the "second system > effect": on one's second try at a particular kind of system, one tends > to add all kinds of bells, whistles, kazoos, etc., vastly > overcomplicating the software. When I first read it, this seemed like > it had to be true, but I haven't seen anyone else discussing it. Does > anyone else have any published references discussing such an effect? > Do y'all believe it's still a problem these days? > > -- This strikes me as asking if anyone has publish their latest failings. I believe quite strongly that there are problems of this kind, but the magnitude is not likely to be discussed openly. The work you cite is most interesting and ought to be a required reading of all CS students. Moreover, required reading by all development managers. The major software/hardware vendor in the U.S. took the time to have a conference in which the sole topic was "The Mythical Man-Month". Upon returning to work the next day, it was as if we never attended ... the same mistakes continued to be made over, and over, and .... I can't relate the number of times that manpower has been dumped upon a project due to scheduling problems. Yet Brooks properly identified "Adding manpower to a late software project makes it later".[pg 25] We read, 'understand', and then so often go on as if we never heard of the subject under discussion (in the general sense). I've said before that the difference between wisdom and knowledge is the ability to USE what one has learned. By not being able to respond to scheduling issues in productive and reasonable ways, software managers often demonstrate lack of wisdom. "Pessimistic" you say? "The difference between a pessimist and an optimist is 24 years experience" Mr Brooks has contributed more understanding of the process of developing software than then industry is capable of assimilating ... even some 16 years later. ---- J.O.Beard jeffb@sharebase.com
kend@data.UUCP (Ken Dickey) (02/23/91)
dalamb@umiacs.umd.edu (David Lamb) writes: >In "The Mythical Man-Month", Fred Brooks (1975) described the "second system >effect" ... >Do y'all believe it's still a problem these days? >David Alex Lamb internet: dalamb@umiacs.umd.edu There is a variant that is also true: arithmetic increases in computing power [by engineering] leading to geometric increases in expectation [by marketing]. A fundamental problem is lack of recognition of differences in scale and what that means for system structuring and complexity. As an analogy, many people have built bridges over streams by throwing a log over them. In the fancy case, use 2 logs and nail some boards between them. To span a ravine, one might use a steel-ibeam/truss design. To get cars and trucks across San Francisco Bay, one might use a suspension design, again with different materials. Many people today are still trying to take high-level assembler/ device-driver technology and scale it up for major software systems and complaining that "it is very difficult to get a log big enough to cross the bay." Unlike engineering professions, many (most?) software professionals are not trained to judge project scale or evaluate software implementation technologies. [In the "real world" I still see many people who could have been bottled in 1975. They are totally unaware that there has been technical progress in software development technology during the intervening years (or for that matter of the advanced techniques available at that time).] So my answers are (10 years in industry) [1] Yes, the "second system" effect is real, and [2] software designers should be aware of "scale shifts" as well. -Ken Dickey kend@data.uucp
rcd@ico.isc.com (Dick Dunn) (02/23/91)
pat@megatest.UUCP (Patrick Powers) writes: > In twelve years in the biz I haven't observed a second system effect. I think there must be some serious differences in understanding what is meant by "second system effect" - because in watching "the biz" for a longer time, I've seen very few pieces of commercial software in the past decade that *haven't* exhibited the second-system effect. You can see it in most commercial UNIX systems, the X Window System, emacs, virtually all PC apps that have been around for a while. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
dalamb@avi.umiacs.umd.edu (David Lamb) (02/23/91)
Earlier, I wrote: >In "The Mythical Man-Month", Fred Brooks (1975) described the "second system >effect" >... >Do y'all believe it's still a problem these days? In an effort to be brief, I think I stated my question unclearly. Lots of people responded by saying "yes, most programs on the market grow chaotically, with lots of bells and whistles". Now, I agree that's a real problem; the Hacker's Dictionary called it Creeping Featurism (CF). But I think the Second System Effect (SSE) may be different; Brooks was talking about designing a new (second) system, not evolving an existing one. The difference is that in SSE one designs an overly complex beast from the beginning, rather than having the beast acquire a kitchen sink as it evolves via CF. So, here's my question again (well, several questions). 1. Is s.s.e still a problem? or do people a. no longer build "second systems", just evolve existing ones b. if they build a "second system", they now avoid the "effect" 2. Regardless of whether SSE is a problem, is it (conceptually) completely dominated by the ill effects of CF? That is, should we ignore it as relatively unimportant, since addressing CF is a. more important b. would also indirectly address SSE as well. I don't have any good idea at the moment of how to combat CF, either, other than appeals to "discipline" and "conceptual integrity" (the latter another term I learned from Brooks). Back when I was one of 3 people in charge of evolving an electronic mail agent, I can recall having several disputes wherein we refused to add new features because they "didn't fit". But we had a captive market and effective "creative control", so we could afford to be arrogant. -- David Alex Lamb internet: dalamb@umiacs.umd.edu
lfd@cbnewsm.att.com (Lee Derbenwick) (02/24/91)
In article <15369@megatest.UUCP>, pat@megatest.UUCP (Patrick Powers) writes: > In twelve years in the biz I haven't observed a second system effect. Perhaps the publicity it got in _The Mythical Man-Month_ actually _taught_ us something? And I think most professional software developers and managers have at least been exposed to the book. Also, most of today's software managers have been software developers long enough to see all (well, many of :-) the things that can go wrong with a project, and they are a little more hesitant to promise the sun, the moon, and the stars. These days, we are more likely to see creeping featurism: where each new release adds just a bit more, until we end up with a full-fledged indigestible fruitcake. Where I have seen something resembling second-system effect is when a hardware manager with no software background (and experience with only relatively small hardware projects) is given a small combined hardwware/software project. It's their first real dealing with software, so they tend to be _very_ careful, and they often succeed quite well. But based on their prior success, they're no longer so careful: they assume that everything that went well on the small project will automatically do so on the large one, that they can prevent those things that did go wrong from happening again, that effort will scale up linearly with project size, and that schedules will scale less than linearly, since they have more people doing the work. So, in bidding the project, they throw in every possible bell and whistle. They then run it using "What's-the-earliest-date-you-can't-prove-it- won't-be-done-by?" [thank you Tom DeMarco, for that phrase] planning, since that's the only way to get a schedule that matches their intuitive expectations. And they are honestly surprised when things don't work out. -- Speaking strictly for myself, -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or <wherever>!att!cbnewsm!lfd
jls@yoda.Rational.COM (Jim Showalter) (02/24/91)
Amen! Software architecture, rather than nitty little issues of this
or that addressing scheme, provide the macro-scale benefits needed to
construct very large systems. And yet, next to nothing is done in this
field, at least in comparison to the amount of effort expended on
relatively low-payoff pursuits like adding multiple inheritance to
some OO language or another. Why? Personally, I think it's because
academics don't BUILD large systems: a large system in most universities
is 50K, and that doesn't count.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine.
-- "When I want your opinion, I'll beat it out of you."jls@yoda.Rational.COM (Jim Showalter) (02/24/91)
I think you either get creeping featurism, in which massive amounts
of new functionality are added in an unplanned and incremental manner,
much like evolution (and about as successfully, if you think about
lower back pain, the veriform appendix, and other goofs!) OR you
get a wish list of deferred features, all of which are designed into
the second system. Which works better? Beats me--I've seen both approaches
fail miserably.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine.
-- "When I want your opinion, I'll beat it out of you."alan@tivoli.UUCP (Alan R. Weiss) (02/26/91)
In article <30512@mimsy.umd.edu> dalamb@umiacs.umd.edu (David Lamb) writes: >In "The Mythical Man-Month", Fred Brooks (1975) described the "second system >effect": on one's second try at a particular kind of system, one tends >to add all kinds of bells, whistles, kazoos, etc., vastly >overcomplicating the software. When I first read it, this seemed like >it had to be true, but I haven't seen anyone else discussing it. Does >anyone else have any published references discussing such an effect? >Do y'all believe it's still a problem these days? > >-- > >David Alex Lamb internet: dalamb@umiacs.umd.edu I have read The Project Manager's Bible (also known as The Mythical Man Month), and yea verily I may speak of heresy, but what the hell, here goes: In my experience the FIRST system is an enormous compendium of features and functions that, sadly, must be whittled down to meer epic/heroic proportions to meet the first release's aggressive schedule (owing no doubt to the supplier of capital's desires to see some payback). My OTHER experience is that often the first system MUST be thrown away, but often is not because: a. It seems to work OK b. Those damn schedules again! Lets ship *something* c. We can fix it all up later. Unfortunately, we often find that fixing it later is a nightmare, because that "little demo" was hacked and kludged in a big hurry. It should be obliterated, but instead the belief is that "we can fix the bugs." No specifications, no design, pure energy. Like an atomic bomb is pure destructive energy awaiting its destiny, these little bombs wait for the future, where they explode into support and maintenance horrors. Graphic, aren't I? :-) _______________________________________________________________________ Alan R. Weiss TIVOLI Systems, Inc. E-mail: alan@tivoli.com 6034 West Courtyard Drive, E-mail: alan@whitney.tivoli.com Suite 210 Voice : (512) 794-9070 Austin, Texas USA 78730 Fax : (512) 794-0623 _______________________________________________________________________
rcd@ico.isc.com (Dick Dunn) (02/26/91)
dalamb@avi.umiacs.umd.edu (David Lamb) writes: > Earlier, I wrote: > >Do y'all believe [second system effect is] still a problem these days? > In an effort to be brief, I think I stated my question unclearly. ...[comparing SSE to feeping creaturism] > ...But I think the Second System Effect (SSE) may be > different; Brooks was talking about designing a new (second) system, > not evolving an existing one... Lamb's points are good ones--in a sense there really is a difference between CF and SSE. But an alternative view is that creeping featurism is just an "implementation technique" used to produce the second-system effect (the final result, anyway:-) incrementally! But CF can be more dangerous because it's seductive--"Well, we just need this one little feature now." Each step you take seems to make sense...so, unlike SSE where the whole thing can collapse in the design phase and (fortunately!) prevent you from ever shipping a product, CF allows you to proceed through to creating a software Frankenstein's monster which is not only un-main- tainable but unkillable. Beyond that, the "failure" is very diffuse, in the sense that the activity which produces the monster is spread out over a long time and a lot of features. You can't point to "the one that made it fail." -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
rcd@ico.isc.com (Dick Dunn) (02/27/91)
alan@tivoli.UUCP (Alan R. Weiss) writes: ... | I have read The Project Manager's Bible (also known as The Mythical | Man Month), and yea verily I may speak of heresy, but what the hell,... | In my experience the FIRST system is an enormous compendium of features | and functions that, sadly, must be whittled down to meer epic/heroic | proportions to meet the first release's aggressive schedule ... | My OTHER experience is that often the first system MUST be thrown | away, but often is not because: There are various reasons for throwing away the first system...no argu- ment there. But why would that be heresy against what is written in _The_Mythical_Man_Month_? Go back and have a look at Chapter 11, the title of which is: Plan to Throw One Away -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
dzoey@terminus.umd.edu (Joe Herman) (02/27/91)
In article <1991Feb26.211223.4180@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >alan@tivoli.UUCP (Alan R. Weiss) writes: >>... >> In my experience the FIRST system is an enormous compendium of features >> and functions that, sadly, must be whittled down to meer epic/heroic >> proportions to meet the first release's aggressive schedule ... Another reason for the enormous compendium of features is that in a new first system, it's hard to know which features will be popular with people. An example of this was not expecting heavy use of electronic mail when ARPAnet was first built. This leads to an attempt to put in the kitchen sink, which is tough to do from scratch. >There are various reasons for throwing away the first system...no argu- >ment there. But why would that be heresy against what is written in >_The_Mythical_Man_Month_? Go back and have a look at Chapter 11, the title >of which is: > Plan to Throw One Away I'm a little unclear of how rapid prototyping interacts with the above principle. Is rapid prototyping an acknowledgement of this principle? Does rapid prototyping lead to creeping featurism? Joe Herman U. of Maryland -- "Everything is wonderful until you know something about it."
alan@tivoli.UUCP (Alan R. Weiss) (02/28/91)
In article <8115@umd5.umd.edu> dzoey@terminus.umd.edu (Joe Herman) writes: >In article <1991Feb26.211223.4180@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >>alan@tivoli.UUCP (Alan R. Weiss) writes: >>>... >>> In my experience the FIRST system is an enormous compendium of features >>> and functions that, sadly, must be whittled down to meer epic/heroic >>> proportions to meet the first release's aggressive schedule ... > >Another reason for the enormous compendium of features is that in a >new first system, it's hard to know which features will be popular >with people. An example of this was not expecting heavy use of >electronic mail when ARPAnet was first built. This leads to an >attempt to put in the kitchen sink, which is tough to do from scratch. ..... Yea, but this is usually caused by developers (and more accurately "Marketing") not *ASKING* their customers what they want. In Tom Peters' terms, "the damn customer doesn't do what (he's) supposed to." Peters', of course, was making the point that American business often fails to *listen* to their customers, and get their feedback during the design stage. Does this sound familiar? _______________________________________________________________________ Alan R. Weiss TIVOLI Systems, Inc. E-mail: alan@tivoli.com 6034 West Courtyard Drive, E-mail: alan@whitney.tivoli.com Suite 210 Voice : (512) 794-9070 Austin, Texas USA 78730 Fax : (512) 794-0623 "I speak only for myself, not for TIVOLI" _______________________________________________________________________
rst@cs.hull.ac.uk (Rob Turner) (02/28/91)
Jerry Gitomer writes: >... I can't think >of any example in which a revised standard has resulted in a >significant reduction in language size or complexity. Nor can I, but something similar is Wirth's simplification of Modula2 (albeit with a few additions) into Oberon. Rob
itcp@praxis.co.uk (Tom Parke) (03/01/91)
rcd@ico.isc.com (Dick Dunn) writes: >pat@megatest.UUCP (Patrick Powers) writes: >> In twelve years in the biz I haven't observed a second system effect. >I think there must be some serious differences in understanding what is >meant by "second system effect" - because in watching "the biz" for a >longer time, I've seen very few pieces of commercial software in the past >decade that *haven't* exhibited the second-system effect. You can see it >in most commercial UNIX systems, the X Window System, emacs, virtually all >PC apps that have been around for a while. Yup, second system effect, been there, done that, got burned. (While in a previous employment I should point out.) I will now do a typical net thing, post what I think is in the book without having it to hand :-( sorry. But its that or not post. Immodesty forbids etc... As I recall the point Brooks is making is not that bells and whistles get added to software - there are good reasons for this, see his "No Silver Bullet" paper (IFIP '86, also published after that in ACM). The point is that on the first system we are conservative, and come version 2 there is a lot of pent up "goodies we couldn't get in first time round" and in the euphoria of "we've done it once we know how to do it a second time" these are added to the spec without due and proper consideration. The effect is a multitude of unforseen interactions between these new features, substantial overruns, code bloat, eventual panic. The possible visible manifestation of this is not software encrusted with features, but announced new versions of software that slip, and slip... and when it arrives it's buggy, DBase IV is a likely candidate. Tom -- Tom Parke (my opinions and spelling are strictly temporary) "UNIX - safe, when taken as directed." itcp@praxis.co.uk
bobd@zaphod.UUCP (Bob Dalgleish) (03/07/91)
In article <1991Feb26.002406.4681@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >dalamb@avi.umiacs.umd.edu (David Lamb) writes: >> Earlier, I wrote: >> >Do y'all believe [second system effect is] still a problem these days? >> In an effort to be brief, I think I stated my question unclearly. >...[comparing SSE to feeping creaturism] >> ...But I think the Second System Effect (SSE) may be >> different; Brooks was talking about designing a new (second) system, >> not evolving an existing one... >Lamb's points are good ones--in a sense there really is a difference >between CF and SSE. But an alternative view is that creeping featurism >is just an "implementation technique" used to produce the second-system >effect (the final result, anyway:-) incrementally! But CF can be more >dangerous because it's seductive-- > . . . Yes, it is seductive... the most expensive part of house renovations is "While we are at it, ..." However, if the features to be added are prompted by actual use of the system by the people who paid for or will pay for the system, the new features will have paid their way into the product. The Second System Effect (I have been there, I have done it) is even more seductive, because the urge to toss out the current grungy product completely and start over with a brand new one is even more seductive. The shiny "system of the future" (turn your reverb up) can excite management and marketing and programmers equally. The real art to Creeping Featurism (IMHO) is to know when to step back and repackage some of the older features and rationalize them together into either a separate package, or a separate menu, or overlay, or whatever the fascicle you use. (<---- that is not swearing, it is technical talk). EVOLUTION TO THE MAX, DUDE! -- -- * * * Remember: I before E except after DALGL * * *-- Bob Dalgleish bobd@zaphod.UUCP