The Mythical Man-Month Notes

Large-system programming

  • a tar pit
  • Evolution of the programming systems product

 

System Test

Thumb for scheduling a software task

  • 1/3 planning
  • 1/6 coding
  • 1/4 component test and early system test
  • 1/4 system test, all components in hand

The Surgical Team

  • The Problem
    • wide productivity variations between good programmers and poor ones
    • sheer number of minds to be coordinated affects the cost of the effort, for the major part of the cost is communication and correcting the ill effects of miscommunication (system debugging)
  • Harlon Mill’s Proposal
    • the surgeon – chief programmer
    • the copilot – less experienced programmer who can do any works
    • the administrator – the boss
    • the editor – takes the draft from the surgeon and criticizes it, reworks it, provides it with references and bibliography
    • two secretaries – one for the administrator one for the editor. handle project correspondence and non-product files
    • the program clerk – maintaining technical records of the team in a programming-product library
    • the toolsmith
    • the tester
    • the language lawyer – experts of programming language

Conceptual Integrity

  • Definition
    • a system omit certain anomalous features and improvements
    • reflect one set of design ideas
    • purpose of a programming system: make a computer easy to use
  • How to achieve
    • improve ratio of function to conceptual complexity
    • system is best in which one can specify things with the most simplicity and straightforwardness
    • architecture: the complete and detailed specification of the user interface
    • the architect of a system, bring professional and technical knowledge to bear in the unalloyed interest of the user

The Joys of the Craft

  1. sheer joy of making things
  2. pleasure of making things that are useful to other people
  3. fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work
  4. the joy of always learning, which springs from the non-repeating nature of the task
  5. delight of working in such a tractable medium

The Woes of the Craft

  1. one must perform perfectly
  2. other people set one’s objectives, provide one’s resources, and furnish one’s information
  3. designing grand concepts is fun; finding nitty little bugs is just work
  4. one finds that debugging has a linear convergence

The obsolescence of an implementation must be measured against other existing implementations, not against unrealized concepts

Men
perfectly partitionable task
Men
unpartitionable task
Months
partitionable task requiring communication
task with complex interrelationships

Passing the Word

Written Specifications – the Manual

  • a necessary tool, not a sufficient one
  • describe everything the user does see, including all interfaces
  • refrain from describing what the user does not see – the implementer’s business
  • could have prose definition

Formal Definitions

  • must be precise
  • tend to be complete
  • embody or describe an implementation of the hardware or software system
  • an implementation can serve as a formal definition
    • questions can be settled unambiguously by experiment
    • could give unexpected and unplanned answers when sharp questions are asked
    • peculiarly susceptible to confusion as to whether the prose description or the formal description is in fact the standard

Direct Incorporation

  • to design the declaration of the passed parameters or shared storage
  • to require the implantations to include that declaration via a compile-time operation

Conferences and Courts

  • proposals are usually distributed in writing before the meeting
  • emphasis is on creativity rather than merely decision

Multiple Implementations

The Telephone Log

Product Test

The Second-System Effect

Interactive Discipline for the Architect

  • When the estimate is too high:
    • cut the design, or
    • challenge the estimate by suggesting cheaper implementations
  • For the second way, to be successful, the architect must:
    • architect suggests, not dictate – the builder has the inventive and creative responsibility for the implementation
    • be prepared to suggest a way of implementing anything he specifies; be prepared to accept any other way that meets the objectives as well
    • dead quietly and privately in such suggestions
    • be ready to forego credit for suggested improvements

Self-Discipline

  • architect doesn’t know what he’s doing – so does it with care and great restraint
  • the first, second and third systems an architect designs

Why Did the Tower of Babel Fail?

A Management Audit of the Babel Project

  • Had:
    • A clear mission?
    • Manpower?
    • Materials?
    • Enough time?
    • Adequate technology?
  • Lacked:
    • communication
    • thus no organization

Communication in the Large Programming Project

  • Informally
  • Meetings
  • Workbook

The Project Workbook

  • What: a structure imposed on the documents that the project will be producing
  • Why:
    • Technical prose is almost immortal
    • Control of the distribution of information
  • Mechanics:
    • Depends on the size of the team
    • Each programmer should see all the material
    • Timely updated

Organization in the Large Programming Project

  • a mission
  • a producer – maybe boss, the director is his right-hand man
  • a technical director or architect – could be the same person as producer – maybe be boss and the producer his right-hand man
  • a schedule
  • a division of labor
  • interface definitions among the parts

Ten Pounds in a Five-Pound Sack

Space Techniques

  • Set total size budges as well as resident-space budgets;
  • Set budgets on backing0-store accesses as well as on sizes
  • Define exactly what a module must do when you specify how big it must be.
  • Space-time trader-offs
    • Ensure programmers are trained in programming technique
    • Recognize that programming has a technology, and components need to be fabricated

The Documentary Hypothesis

Why Have Formal Documents

Software Project Documents

  • What: objectives
  • What: product specifications
  • When: schedule
  • How much: budget
  • Where: space allocation
  • Who: organization chart

Plan to throw One way

Prepare Organization for Change

  • Senior persons must be kept technically and emotionally ready to manage groups or to be delight to build the programs with their own hands
    • Managers sent to technical refresher courses
    • Senior technical persons learn management

Hoatching a Catastrophe

Milestones

  • First, have a schedule
  • milestones should be sharp-edged and unambiguous
  • PERT technique
    • a graphical representation of the project
    • Program/project evaluation review technique

The Whole and the Parts

Designing the Bugs Out

  • Bug-proof the definition
    • Conceptual integrity of the product not only makes it easier to use, it also makes it easier to build and less subject to bugs
    • the specification must be handed to an outside testing group to be scrutinized for completeness and clarity
  • Top-down design
    • refinement steps, identifies modules
  • Structured programming

Component Debugging

  • On-machine debugging
  • Memory dumps
  • Snapshots
  • Interactive debugging

The Other Face

What Documentation is Required?

  • To use a program
    • Purpose
    • Environment
    • Domain and range
    • Functions realized and algorithms used
    • Input-output formats
    • Operating instructions
    • Options
    • Running time
    • Accuracy and checking
  • To believe a program
    • every copy of program shipped should include some small test cases that can be routinely used to reassure the user that he has a faithful copy, accurately loaded in to the machine
  • To modify a program

The document approach

  • carry as much of the documentation in the program source code as possible
  • use space and format as much as possible to improve readability
  • insert the necessary prose documentation into the program

No Silver Bullet

Essential Tasks

  • Exploiting the mass market to avoid constructing what can be bought
  • Using rapid prototyping as part of a planned iteration in establishing software requirements
  • Growing software organically, adding more and more function to systems as they are run, used, and tested.
  • Identifying and developing the great conceptual designers of the rising generation

No inventions that will do for software productivity, reliability, and simplicity what those did for computer hardware.

Leave a Reply