Software Management Lessons
from the 1960s

Larry Garfield


Larry implements Huggable
  • Director of DX,
  • PHP-FIG Core Committee
  • implements Huggable

IBM System/360

IBM System/360 Model 20
IBM 2311 Memory Unit


  • 8-bit byte
  • Byte-addressable memory

Lives on as IBM zSeries

Glowing IBM zSeries computer

Lead team

Lead architect

Gene Amdahl
Gene Amdahl

Lead manager

Fred Brooks
Fred Brooks

"The Mythical Man Month"


The Mythical Man Month

Anniversary edition, 1995

It's been another 20(-ish) years...

Is it still valid?

Brooks Law

Communication is hard

4 actors requires 6 communication channels

Tasks are not parallelizable

300 people can do it in a day

Even for Unskilled tasks

Adding people incurs cost

More people takes more time

(Depending on swim lanes,
and how early)

Amdahl's law

Amdahl's Law
Graph of Amdahl's Law

Is it still true?


5400 Contributors to Drupal 8

What should we learn from this?

Why are estimates always wrong?

Programming Systems Product

It takes 9x as much work to fully productize a program

A substantial bank of test cases, exploring the input range and probing its boundaries, must be prepared, run, and recorded.

—Page 6

Automated testing was already a thing in 1975.

What's your excuse?

How fast can you code?

Extrapolation of times for the hundred-yard-dash shows that a man can run a mile in under 3 minutes.

—Page 88

Effort = Constant * NumInstructions1.5

It takes longer per line the more lines you have

—Nanus and Farr, Page 89

Productivity in large systems
Num interactions Instructions per person-year
Very few 10,000
Some 5,000
Many 1,500

Joel Aron, Page 90

Large: 25 programmers, 30,000 instructions

But that's for assembly!

PL/I code follows same curve ...for statements

More power/statement => more productivity

Is it still true?


2176 Contributors to Symfony 4, 10 May 2019

Lines of code in Symfony 4: 511369

What should we learn from this?

Planning and Documentation

Top-down design

  • Architect first
  • Refine top-down to produce modules
  • Recurse until you have an architecture
  • Implement each module
  • Debug/test each module separately
  • Inform back up as needed

Divide and conquer

Don't go developing waterfall

Design top-down, implement iteratively


  • End-to-end skeleton
  • Always Be Compiling
  • Grow modules in place
  • Throw away modules piecemeal as needed



Agile MVP is wrong



How MVP really works


Is it still true?


"No Silver Bullet"


Essential Complexity

The problem space is hard

Accidental Complexity

The tools are hard to use

Attacking essential complexity

  • Rapid prototyping, grow organically, user-feedback
  • "Buy versus Build"
  • Mentor better architects

Hey, look, Open Source!

The logo of the Open Source Initiative

The way to be more productive is to write less code

The way to be more productive is to reuse more code

Growing great designers

Growing great designers


  • Identify candidates early (may not be most experienced)
  • Assign a career mentor
  • Apprenticeships, formal education, short courses, solo work
  • Encourage collaboration with other designers

Is it still true?


Conceptual integrity

Ease of use = functionality / conceptual complexity


Smart division of labor


But that's Cathedral design; that's aristocracy!

Cathedrals are still standing...

See also

  • Apple
  • Google
  • Unix / Posix
  • HTTP / Browsers


Designs watch dial and hands


Builds gears and bells

Ongoing cooperative effort, high communication


What should we learn from this?

How big is big?

What should we learn from this?

  • Software construction is a creative process
  • Divide and conquer
  • Shareable programming systems products (Open Source)
  • Decouple libraries from framework
  • Top-down design
  • Empower architect to make decisions

Larry Garfield


Director of Developer Experience

Idea to Cloud Hosting

Stalk us at @PlatformSH