Software Management Lessons from the 1960s

Presented by Larry Garfield (@Crell)

@Crell

Larry implements Huggable
  • D.R.I.E.S., Platform.sh
  • 10 years consulting with Palantir.net
  • Drupal 8 Web Services Lead
  • implements Huggable

IBM System/360

IBM System/360 Model 20

Announced 1964

IBM 2311 Memory Unit

Legacy

  • 8-bit byte
  • Byte-addressable memory
  • EBCDIC

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"

1975

The Mythical Man Month

Anniversary edition, 1995

It's been another 20 years...

Is it still valid?

Brooks Law

Adding [people] to a late software project makes it later.

The Mythical Man-Month

Communication is hard

4 actors requires 6 communication channels
(n(n-1))/2

Tasks are not parallelizable

300 people can do it in a day

Even for Unskilled tasks

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

The Mythical Man-Month, page 16

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?

Yup

Drupal
3715 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?

Yup

3715 Contributors to Drupal 8

Lines of code in Drupal 8: 237198

Source: https://infogr.am/Drupal-Code-Base

What should we learn from this?

Planning and Documentation

Only when one writes do the gaps appear and the inconsistencies protrude. The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact policies from fuzzy ones.

—Page 111

The manual, or written specification, is a necessary tool, though not a sufficient one.

—Page 62

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

Plan to throw one away; you will, anyhow.

—Page 116

Don't go developing waterfall

Design top-down, implement iteratively

1995

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

Refactoring!

The approach necessitates top-down design, for it is a top-down growing of the software.

—Page 201

Common sense, if not common practice, dictates that one should begin system debugging only after the pieces seem to work.

—Page 147

Agile?

Agile MVP is wrong

Wrong!

How MVP really works

Is it still true?

Yup

"No Silver Bullet"

1986

Essential Complexity

The problem space is hard

Accidental Complexity

The tools are hard to use

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

—Page 182

There is no single development... which by itself promises even one order of magnitude improvement in productivity, in reliablity, in simplicity

—Page 183

Attacking essential complexity

  • Rapid prototyping, grow organically, user-feedback
  • "Buy versus Build"
  • Mentor better architects
The most radical possible solution for constructing software is not to
construct it at all.

—Page 197

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

Software construction is a creative process.

—Page 202

Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.

—Page 202

Mentoring

  • 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?

Yup

Conceptual integrity

The conceptual integrity of the product, as perceived by the user, is the most important factor in ease of use.

—Page 255

Ease of use = functionality / conceptual complexity

Simplicity and straightforwardness proceed from conceptual integrity.

—Page 44

Conceptual integrity is the most important consideration in system design.

—Page 42

...conceptual integrity of the product not only makes it easier to use, it also makes it easier to build and less subject to bugs.

—Page 142

How?

Smart division of labor

The design must proceed from one mind, or a very small number of agreeing,
resonant minds.

—Page 44

Architect/designer

The architect… is the user's agent. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user, as opposed to the interest of the salesman, the fabricator, etc.

—Page 45

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

Cathedrals are still standing...

See also

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

Architect

Designs watch dial and hands

Implementer

Builds gears and bells

The architect must always be prepared to show an implementation for any feature he describes, but he must not attempt to dictate the implementation.

—Page 62

Ongoing cooperative effort, high communication

PHP
Drupal
Drupal 8

What should we learn from this?

How big is big?

After teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager and a separate architect.

—Page 257

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
The idea that people knew a thing or two in the '70s is strange to a lot of young programmers.

Donald Knuth

Larry Garfield

Director of Runtimes and Integrations Platform.sh

Continuous Deployment Cloud Hosting

Stalk us at @PlatformSH