From: mberkley@visions.uvic.ca (Mike  Berkley)
Subject: REVISITING THE MYTHICAL MAN-MONTH
Summary: This is a short (5 question) software engineering course survey.
Reply-To: mberkley@sirius.uvic.ca (J. Michael Berkley)
Organization: University of Victoria
Distribution: comp
Date: 11 Nov 92 12:14:07

(This survey is being posted for a friend without Usenet access.)

Please give this survey the widest possible distribution.  The survey has
only five questions.  I am especially interested in the comments of people
who have experience designing and building large software projects.


                ****************************************
                *                                      *
                *   REVISITING THE MYTHICAL MAN-MONTH  *
                *                                      *
                ****************************************

****************
* INTRODUCTION *
****************

It has been seventeen years since Fredrick P. Brooks, Jr. published THE 
MYTHICAL MAN-MONTH, a seminal book of essays on Software Engineering.  His 
very readable book contains many insights into the discipline, and is still
widely quoted.

Although much of what he wrote is current, some of his ideas are not reflected 
in recent literature.  I am considering which of his ideas are still    
current, and how Software Engineering has evolved from his insights.  I 
would appreciate it if you could assist me by taking the time to answer the 
following questions.  Feel free to say as much as you like, or give yes/no 
answers.    

ALL OF THE QUESTIONS IN THIS SURVEY DEAL WITH LARGE SOFTWARE PROJECTS.

All responses will be kept confidential.  Please send your responses to: 

savage@cmr.ca 

I would appreciate receiving your response by November 21st, but any
submission received by November 28th will be useful.

This research is part of a project for a graduate course in Software
Engineering.  Please indicate any bulletin board you would like the final
report posted to, or send me your E-Mail address if you would like a personal 
copy.  I will get it to you by 16 Dec 92.

**************
* THE SURVEY *              
**************

Please answer as many or as few of the following biographical questions as
you wish too.  Responses of "negligible", "basic", or "extensive" will be
sufficient.

My formal training in Software Engineering is .....


My experience in writing software specification is .....


My experience is software design is ....


My experience in programming is ....


My experience in debugging software is ....


My experience in maintaining software is ....


My experience in managing software projects is ....


I have .... years experienceh working on large software projects. 

My present role in software development is ....



* Background to question 1.  CONCEPTUAL INTEGRITY 
Brooks contends that conceptual integrity is the most important consideration
when designing a large software product.  He says that design must proceed 
from one mind, or from a very small number of agreeing resonant minds.
Brooks says that conceptual integrity is critical because it reduces the cost 
of communication in designing a software product, reduces the number of bugs 
designed into the system, and results in a system that goes together faster.  
Brooks dedicates the first half of his book to exploring why conceptual 
integrity is difficult to achieve, and methods for achieving it.  He asserts
that the most pernicious and subtle bugs are system bugs arising from
mismatched assumptions made by the authors of various components. 
  Yet the need for conceptual integrity is one of the least quoted of 
Brooks's ideas.  Maybe conceptual integrity was never that important, or  
maybe more modern design techniques make conceptual integrity easier to 
achieve amongst larger design teams.  Perhaps the need for conceptual
integrity is such an obvious and basic requirement that it seldom needs 
mentioning, or it might be that we still need to learn the most important 
lesson that Brooks has to teach us.

THE MOST IMPORTANT QUESTION
***************************

Question 1.  Is conceptual integrity the most important consideration when
designing a large software product.  If it is, why isn't the need for 
it mentioned more often in Software Engineering literature?




















* Background to question 2.  COMMUNICATIONS WITHIN A SOFTWARE TEAM
Brooks says "Communication and its consequent, organization, are critical
for success.  The techniques of communication and organization demand from
the manager as much thought and as much experience as the software technology
itself."  Some of the communication techniques that he suggests are:
        - weekly conferences of designers, programmers, and market planners
          to discuss problems;
        - semi-annual "supreme court sessions" to clear backlogs of 
          open issues; 
        - a formalized way of letting everyone involved in a project know
          about minor decissions made informally, such as the response to a
          question asked during a telephone conversation; and

  These are to avoid the "schedule disasters, functional misfits, and system
bugs (that) arise because the left hand doesn't know what the right hand
is doing."  With reguard to software specifications, the author states that
natural language and formal notations are equally good for writing software
specifications, provided that if both are used then it is clearly stated
which is the primary specification.

Question 2.  Do you agree with Brooks's statements about communications.




















* Background to question 3.  SCHEDULING AND MANAGEMENT
The chapters from THE MYTHICAL MAN-MONTH on scheduling and management contain
many pearls of software engineering wisdom, such as:

        Disasters are usually due to termites, not tornadoes.

or the rhetorical question and answer

        How does a project get to be a year late?
        ... One day at a time.

and Brooks's Law, which states

        Adding manpower to a late software project makes it later.

The author claims that more software projects have gone awry for lack of
calendar time than for all other causes combined.  He gives five reasons for
this common disaster, as he perceived the problem in 1975:
        - techniques of estimating schedules were poorly developed, and
          reflected unwarranted optimism about the number of bugs in the
          code;
        - estimating techniques confused effort with progress, hiding the
          assumption that men and months are interchangeable;
        - because we were uncertain of our estimates, software managers 
          would bow to pressure to give optimistic completion dates;
        - schedule progress was poorly monitored; and
        - when slippage was recognized the natural response was to add
          manpower, which Brooks describes as dousing a fire with gasoline.
He also saw that most programming groups suffered from too little management
rather than too much, and that schedule monitoring techniques proven and
routine in other engineering disciplines were considered radical innovations
in software engineering.

Question 3.  Has our ability to schedule and manage software projects 
improved since 1975?




















* Background to question 4.  THE SURGICAL (CHIEF PROGRAMMING) TEAM
An alternative model for organizing a programming team is the Chief 
Programming Team (or Surgical Team) method.  Instead of dividing all tasks
equally amongst all team members, tasks are specialized.  The team is lead
by a chief programmer who is an experienced and highly qualified individual.
He and his assitant write all of the code and documentation.  Other members
of the team carry out specific functions such as librarian, toolsmith,
tester, etc.  Brooks says that such an organization makes best use of your
most experienced programmers, and aides conceptual integrity by reducing the
number of minds that must be coordinated to build good software.

Question 4.  Is the Chief Programmer Team model used in practice?  If so, do 
such teams work better then conventionally organized teams?




















* Background to question 5.  TESTING AND TOOLS
Brooks places great importance on software tools and testing, both being  
supported by dedicated resources.  He believes that it is inefficient for
each programmer to have their own file of programming tools.  Rather, there
should be a library of tools and a "toolsmith" to make any new tools that
are required.
  Brooks strongly advocates thorough testing of each software component
before it is integrated with others.  He uses the term "scaffolding" to 
describe software that is written specifically for testing, and says that
it is reasonable for there to be half as much code for programs and data for
debugging the system as there will be for the final product.  According to
Brooks, fixing a defect has a 20 to 50% chance of introducing a new defect.
Therefore, rigorous testing and quantizing changes during development are
essential.  These practices will also result in a system that will fit
together and be working sooner than one built with a "let's put it together
and see if it works" approach.
  Lastly, Brooks supports having an independant product testing team that
serves as a devil's advocate, and checks the product against its
specifications.

Question 5.  Do you agree with Brooks's statements about testing and tools?




















Question 6.  BONUS QUESTION
Have you worked in a software organization that had a matrix-like
organizational structure, rather than a tree-like one?  How well did it
work?










**************
* CONCLUSION *
**************

Thank you for completing this survey.  If you have not read THE MYTHICAL
MAN-MONTH, I highly recommend it to you.  Most of its contents are still
very pertinent, and it is enjoyable reading.

The Mythical Man-Month - Essays on Software Engineering
Fredrick P. Brooks, Jr.
Addison-Wesley Publishing Company; 1975, 1982
ISBN 0-201-00650-2
        BB-AL-89
Newsgroups: comp.software-eng