No Silver Bullet

~ Dr. Fred Brooks ~

(1985)

I "liked" this paper, but ...

Influence

  • System/360
  • OS/360

S360 Features

  • 8-bit Byte
  • Byte Addressable Memory
  • 32-Bit Words
  • 9 track tape

Problems

  • Multiple OS across Multiple Machines
  • TSS/360 Never Released
  • OS/360 Year Late
  • Significantly Over Budget
  • Heavy Resource Consumer
  • Personnel Loss from Fatigue

Software Crisis

How does a project get to be a year late?... One day at a time. - Mythical Man Month [p153]

"The time has arrived to switch from home-made software to manufactured software, from tinkering to engineering - twelve year after a similar transition has taken place in the computer hardware field ... it is high time to take this step. The use of computer has reached the stage that software production ... has become a bottleneck for further expansion" - Bauer @ 1968 Software Engineering Conference

So what is this paper?

Mythical Man Month

  • External interfaces before internal implementations.
  • Great Designers Design Great Things.
  • Good management leads to good implementations.
  • Adding labor to a late project only makes the project later.
  • Programming requires communication.

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication between them.

Since software construction is inherently a systems effort - an exercise in complex interrelationships - communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule.

Programming Requires Communication

There are only two problems in software and it's communication.

Order of What?

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.

The Roots?

" If software development were to continue to be the same clumsy and expensive process as it is now, things would get completely out of balance. You cannot expect society to accept this, and therefore we must learn to program an order of magnitude more effectively. To put it in another way: as long as machines were the largest item on the budget, the programming profession could get away with its clumsy techniques, but that umbrella will fold rapidly." - Dijkstra

Improve ALL THE THINGS!

  • Productivity
  • Reliability
  • Simplicity

Essential vs Accidental Complexity

  • Essential - complexity arising because of the nature of software
  • Accidental - complexity arising from production of software

Brooks suggests that most techniques attack the accidents of software engineering.

Essential Difficulties

  • Complexity
  • Conformity
  • Changeability
  • Invisibility

Complexity

  • Software is complex for its size
  • Lots of state
  • Essential Complexity increases non-linearly w/size
  • Complexity is intrinsic in many domains

Complexity creates:

  • Communication problems (MMM)
  • Flaws, overruns, delays
  • Lots of possible states
  • Lack of extensibility
  • Unrecognized state leads to security flaws
  • Steep learning curves put pressure on labor turn-over

Conformity

  • Humans design poor interfaces, therefore complexity
  • Software must conform:
    • because it's the newest tech
    • because it's the most conformable

Changeability

  • Software constantly subject to pressures for change
  • Argues manufactured products rarely change after manufacture
  • Software is 'thought stuff', infinitely malleable
  • Designed for Hardware which it outlives

We change software due to edge cases or success drives further innovation

Invisibility

  • UML
  • Domain Driven Design
  • Functional Programming
    • Domain & Range
    • Map X => Y
    • Filter X where Y
    • Reduce X,Y => Z
  • MIT's Scratch, Labview, etc.

Invisibility cont.

  • Software diagrams (complex systems) are several directed graphs, super-imposed
  • Graphs Represent
    • Flow Control
    • Patterns of Dependency
    • Time Sequence
    • Name-Space Relationships

The software task

  • Buy don't Build
  • Incremental & Iterative Development
  • Prototype, Prototype, Prototype
  • Identify & Develop Great Designers

Agile, you'd think it started with a manifesto?

"We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's ServiceBureau Corporation]." - Larman

"If the waterfall model risks not building the right product, then agile risks not building the product right. I’m very fond of Erlang creator Mike Williams point: “If you don’t make experiments before starting a project, then your whole project will be an experiment”. My hunch is what a lot of Agile process misses is that you need to experiment before you build." - Jesper Louis Andersen

Requirements & the Prototype

  • Clear argument for prototyping
  • Evolution of MMM's Second System Argument
  • Sets up case for (a)gile

Write Software, Grow Systems

Brooks proposes top down, fill in the blank design ~rewarding~

The Great Designer

  • Identification
  • Career Development & Mentorship
  • Interactions

"Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated" - Dijkstra

"The one opinion was that a really competent programmer should be puzzle-minded and very fond of clever tricks; the other opinion was that programming was nothing more than optimizing the efficiency of the computational process, in one direction or the other." - Dijkstra

Why do we need a "silver bullet"?

  • Software Crisis
  • Coupled to Hardware due to limited abstractions

Price to Performance gains

  • Commoditized Software engineering
  • Cost Cutting
  • Software Engineering Crisis

"There seem to be three major conditions that must be fulfilled. The world at large must recognize the need for the change; secondly the economic need for it must be sufficiently strong; and, thirdly, the change must be technically feasible." - Dijkstra

What's Really Hard?

  • Specification & Estimation
  • Design
  • Testing

What Did Brooks Miss?

  • We've No Context
  • OS/Tools vs. Product/Contracting
  • Achieving for ourselves vs. target domain

Things To Think On

  • Why do we impose scientific reasoning/rigor on the systems crafted by humans, but not the system of humans that crafted them?
  • Should we ever write formal process papers that neglect to mention context?

Links & Research

Links & Research cont.