Lecture: Brooks: The mythical man-month revisited
schaad rene
_________________________________________________________________
THE MYTHICAL MAN-MONTH REVISITED
================================
by F.P. Brooks, Jr.
Notes from a lecture given at the
ETH Zurich, Switzerland, on Nov 11, 1991.
Protocol by Rene Schaad (sch...@ifi.unizh.ch).
_________________________________________________________________
1. Introduction.
2. Where I was wrong.
3. Where the world has changed.
4. Positions I still hold strongly.
5. What I've learned new.
_________________________________________________________________
1. Introduction
---------------
- The book (the mythical man-month) is really about: "Software-
Engineering (SE) is different, but not that different."
- SE is about scaling up.
- Definition of SE: making programming system products.
_________________________________________________________________
2. Where I was wrong
--------------------
a. I OVERESTIMATED the non-linear growth of effort
size. But project size effects really do matter.
b. "Plan to throw one away": I would now recommend this for
bad teams only. Now, I suggest you make schedules on previous
experience of your team. My new approach: INCREMENTAL SE, i.e.
build a small functionally limited but working system and then
expand it.
c. Chief programmer team concept (the surgical team approach):
This idea was not picked up. Reasons: there are no good chief
programmers / it's against corporate culture (manager must be
more important that technician). But I still think that it's
generally a good idea.
_________________________________________________________________
3. Where the world has changed
------------------------------
a. Program space as substantial cost: this is not valid anymore.
But: good programs are still small in size.
Nevertheless: don't waste time space-optimizing software.
b. Sharp tools are there today. But there's too much emphasis on
tools, and too little on design.
_________________________________________________________________
4. Positions I still hold strongly
----------------------------------
a. Conceptual integrety and the whole architect concept.
-> System engineers are needed. Someone who understands all
of the systems design. Someone who understands all of the user
interface.
b. Good programmers are much much better than average programmers.
They are 4 - 10 times faster. Use good programmers and
grow them. Use bad ones for assistants or don't use them.
Categories: - "Hackers": quite good programmers
- "Computer Charmers": very rare, super-good,
arrange your company around them.
c. Data representation is the essence of programming.
Algorithms are built around them.
d. Brooks law: "Putting manpower into a late project makes it later".
e. SE is fundamentally a control problem.
- Architectural and conceptual control.
- Specification by incorporation (Macintosh).
- Documentation control.
- Code control.
- Schedule control ("Schedule slips one day at a time").
f. More is less.
- More design is less coding.
- More scaffolding is less work.
- More integration control is less total work.
- Building twice can be faster.
g. Less is more.
- Brooks law.
- Chief programmer concept.
- Don't write programs.
_________________________________________________________________
4. What I've learned new.
-------------------------
(Appeared in "No silver bullet." in Computer Magazine, Vol. 20,
No. 4, April 1987)
a. Programming is fundamentally a social activity.
Two is an optimal team size. Four is next best.
b. What should we do?
- Object oriented programming is outgrowth of structured
programming. Use it. It's good.
- Buy, don't build (B. Boehm).
- Use rapid prototyping, especially for user interfaces.
- Incremental development (Mills).
- Grow gread designers ! (Most important for managers.)
_________________________________________________________________
_________________________________________________________________
Please send comments, questions, additions,
--
Rene Schaad | sch...@ifi.unizh.ch | sch...@iis.ethz.ch |
Cameron Laird
>To all of those who read the book but could not attend the talk.
>
>_________________________________________________________________
>
>
> THE MYTHICAL MAN-MONTH REVISITED
> ================================
>
> by F.P. Brooks, Jr.
>
>
> Notes from a lecture given at the
> ETH Zurich, Switzerland, on Nov 11, 1991.
> Protocol by Rene Schaad (sch...@ifi.unizh.ch).
one of my first edicts will be, "A Very Good
Use of the Net is to post lecture- and book-
reviews." Thank you, M. Schaad.
.
.
.
>c. Chief programmer team concept (the surgical team approach):
> This idea was not picked up. Reasons: there are no good chief
> programmers / it's against corporate culture (manager must be
> more important that technician). But I still think that it's
> generally a good idea.
claim that it wasn't picked up because "it's
against corporate culture", but this isn't
the place for them. What's the latest from
those who have tried? Any readers have re-
cent results?
.
.
.
>4. Positions I still hold strongly
>----------------------------------
>
>a. Conceptual integrety and the whole architect concept.
> -> System engineers are needed. Someone who understands all
> of the systems design. Someone who understands all of the user
> interface.
>
>b. Good programmers are much much better than average programmers.
> They are 4 - 10 times faster. Use good programmers and
> grow them. Use bad ones for assistants or don't use them.
> Categories: - "Hackers": quite good programmers
> - "Computer Charmers": very rare, super-good,
> arrange your company around them.
>
>c. Data representation is the essence of programming.
> Algorithms are built around them.
personal list of the most important discover-
ies.
In
Erickson, J. David
1993 "Beyond Systems: Better Understanding
the User's World", Computer Language,
volume 10, number 3 (March 1993)
the author proposes that "the language/action
perspective allows the designer to directly
perceive how the user decides when and where
automated tools might be necessary" so well as
to *supplant* Systems Analysis in its restricted,
data-oriented sense. The article didn't persuade
me. Erickson credits Winogrand and Flores for
the perspective. Do any c.s-e readers have more
to report on the proposition that language/action
analysis can appropriately replace data-oriented
systems analysis?
.
.
.
--
Cameron Laird
cla...@Neosoft.com (claird%Neoso...@uunet.uu.net) +1 713 267 7966
cla...@litwin.com (claird%litwi...@uunet.uu.net) +1 713 996 8546
Larry Weiss
>In article <1993Feb13.1...@ifi.unizh.ch> sch...@avalon.physik.unizh.ch (schaad rene) writes:
>>To all of those who read the book but could not attend the talk.
>>
>>_________________________________________________________________
>>
>>
>> THE MYTHICAL MAN-MONTH REVISITED
>> ================================
>>
>> by F.P. Brooks, Jr.
>>
>>
>> Notes from a lecture given at the
>> ETH Zurich, Switzerland, on Nov 11, 1991.
>> Protocol by Rene Schaad (sch...@ifi.unizh.ch).
I just tapped into this newsgroup. Can the above text be re-posted?
Is it archived somewhere? Thanks!