The Mythical Man-Month by Fred Brooks (I)

1
The Mythical Man-Monthby Fred Brooks (I)

• Published 1975, Republished 1995
• Experience managing the development of OS/360
  in 1964-65
• Central Argument
• Large programming projects suffer management
  problems different in kind than small ones, due
  to division of labor.
• Critical need is the preservation of the
  conceptual integrity of the product itself.

2
The Mythical Man-Monthby Fred Brooks (II)

• Central Conclusions
• Conceptual integrity achieved through exceptional
  designer
• Implementation achieved through well-managed
  effort
• Brookss Law Adding personnel to a late project
  makes it later

3
No Silver Bulletby Fred Brooks (1987)

• There is no single development, in either
  technology or management technique, which by
  itself promises even one order-of-magnitude
  improvement within a decade in productivity, in
  reliability, in simplicity.

4
Why Is This a Safe Bet?

• All software construction involves essential
  tasks, the fashioning of the complex conceptual
  structures that compose the abstract software
  entity, and accidental tasks, the representation
  of these abstract entities in programming
  languages within space and speed constraints.
  How much of what software engineers now do is
  still devoted to the accidental, as opposed to
  the essential? Unless it is more than 9/10 of
  all effort, shrinking all accidental activities
  to zero time will not give an order of magnitude
  improvement.

5
Essence v. Accident

• Essence the difficulties inherent in the nature
  of the software
• Accidents those difficulties that today attend
  its production but that are not inherent

6
Accidental Difficulties

• Solutions potentially exist
• Past productivity increases result of overcoming
  prior accidental difficulties
• Inadequate programming constructs abstractions
• Remedied by high-level programming languages
• Increased productivity by factor of five
• Complexity was never inherent in program at all

7
Accidental Difficulties (contd)

• Past productivity increases result of overcoming
  (contd)
• Viewing results of programming decisions took
  long time
• Remedied by timesharing
• Turnaround time approaching limit of human
  perception
• Difficulty of using heterogeneous programs
• Addressed by integrated software development
  environments
• Support task that was conceptually always possible

8
Essential Difficulties

• Only partial solutions exist for them, if any
• Cannot be abstracted away
• Complexity
• Conformity
• Changeability
• Intangibility

9
Complexity

• No two software parts are alike
• If they are, they are abstracted away into one
• Complexity grows non-linearly with size
• E.g., it is impossible to enumerate all states of
  program (Except perhaps toy programs)

10
Conformity

• Software is required to conform to its
• Operating environment
• Hardware
• Often last kid on block
• Perceived as most conformable

11
Changeability

• Change originates with
• New applications, users, machines, standards,
  laws
• Hardware problems
• Software is viewed as infinitely malleable

12
Intangibility

• Software is not embedded in space
• Often no constraining physical laws
• No obvious representation
• E.g., familiar geometric shapes

13
Pewter Bullets

• Ada, C, Java and other highlevel languages
• Object-oriented design/analysis/programming
• Artificial Intelligence
• Automatic Programming
• Graphical Programming
• Program Verification
• Environments tools
• Workstations

14
Promising Attacks On Complexity (In 1987)

• Buy vs. Build
• Requirements refinement rapid prototyping
• Hardest part is deciding what to build (or buy?)
• Must show product to customer to get complete
  specification
• Need for iterative feedback

15
Promising Attacks On Complexity (contd)

• Incremental/Evolutionary/Spiral Development
• Grow systems, dont build them
• Good for morale
• Easy backtracking
• Early prototypes
• Great designers
• Good design can be taught great design cannot
• Bottom line Nurture great designers

16
Software Architecture (and Architects)

• Software Engineers have always employed software
  architectures
• Very often without realizing it!
• Address issues identified by researchers and
  practitioners
• Essential software engineering difficulties
• Unique characteristics of programming-in-the-large
  
• Need for software reuse
• Many ideas originated in other (non-computing)
  domains

17
Primacy of Design

• Software engineers collect requirements, code,
  test, integrate, configure, etc.
• An architecture-centric approach to software
  engineering places an emphasis on design
• Design pervades the engineering activity from the
  very beginning
• But how do we go about the task of architectural
  design?