Management Lessons from the 1960s

@Crell

Software Management Lessons
from the 1960s

Larry Garfield

@Crell

Larry implements Huggable

Director of DX, Platform.sh
PHP-FIG Core Committee
implements Huggable

IBM System/360

IBM System/360 Model 20

System 360 Model 20
Announced 1964
First complete range of compatible computers
Distinction between architecture and implementation
Developed over 2 years, shipped over 10

IBM 2311 Memory Unit

Tapes or spinning disk

Legacy

8-bit byte
Byte-addressable memory
EBCDIC

8-bit allowed lowercase letters

Lives on as IBM zSeries

Glowing IBM zSeries computer

Still BC for many programs
Yes, zSeries runs PHP

Lead team

Lead architect

Gene Amdahl

Lead manager

Fred Brooks

Brooks coined the term "computer architecture"

"The Mythical Man Month"

1975

The Mythical Man Month

Anniversary edition, 1995

Lessons learned, experience and academic study
New edition includes "No Silver Bullet", 1986
Revisit original claims, still true?
Mostly, yes

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

Is it still valid?

Different outline from Brooks, same ideas
Not valid: "man" month
Picking on OSS projects, but not them specifically

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$

More people = more communication channels

Tasks are not parallelizable

300 people can do it in a day

Even for Unskilled tasks

Some resources limited
Diff skill levels
Some tasks block others

[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)

Projects have natural number of swim lanes
That's max # of developers
Developers != people involved

Amdahl's law

$Amdahl's Law$

Graph of Amdahl's Law

"gives the theoretical speedup in latency of the execution of a task at fixed workload that can be expected of a system whose resources are improved."

Is it still true?

Yup

@Crell Get a second speaker on stage, and give both halves of the talk simultaneously. You'll be able to fit in 2x the material.
— Greg Anderson (@greg_1_anderson) September 7, 2016

Any projects that throw people at a problem?

Contributors to TYPO3: 486

What should we learn from this?

As of 2 October 2019

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

3x time to flesh out, test, error handling, etc.
3x time to make stable external interfaces
"Fast garage products" are just the top-left

Automated testing was already a thing in 1975.

What's your excuse?

Not that tests take 3x as long
Fixing the bugs tests find takes that long

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

Current best is 3:43.13

Effort = Constant * NumInstructions^1.5

It takes longer per line the more lines you have

—Nanus and Farr, Page 89

True even if no communication!
More interaction points internally
Limits of human memory

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

Brooks is 2 for 2
25 programmers, 30,000 instructions?

Lines of code in TYPO3: 692618

What should we learn from this?

As of 2 October 2019

Planning and Documentation

These go hand-in-hand.
Why up-front-docs?

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

It's like rubber ducking with a word processor

The crucial task is to get the product defined. Many, many failures concern exactly those aspects that were never quite specified.

Page 142 via V.A. Vyssotsky of Bell Labs Safeguard Project

If you don't know what you're building, you can't built it well.

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

Page 62

Formal definition (Code): Precise, but not very readable
Misses the "why" of prose.

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 know what you don't know until you build it wrong
Never ship v1. See also: Windows 1, 2; MS takes until v3 to be good

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!

Skeleton may take a long time!
Refactoring is the art of throwing it away a little bit at a time

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

Architect top-down
Debug bottom-up

Agile?

Agile MVP is wrong

Wrong!

This is throwing it away, twice!

Agile?

How MVP really works

(Credit: http://comunidad.iebschool.com/)

Start with a skeleton that supports your end goal
Replace doors as needed
Decoupled components!
NOT most important feature first; foundation first

Is it still true?

Yup

2.5 for 3

"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

Execute by walking down hall to computer room
Debugging by punch card

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

Page 183

There is room for improvement, but not like we once saw

Attacking essential complexity

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

Already covered the first one

The most radical possible solution for constructing software is not to
construct it at all.

Page 197

Hardware $20 million, $50k custom software cheap
$10 computer => software expensive to write
Reuse software tools and components

Hey, look, Open Source!

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

Growing great designers

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

Software architecture more like graphic design than engineering
Architecture is a separate skill set
Needs recognition as equal with management

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

Things the design world does. This is design. We need it too.

Is it still true?

Yup

Got OSS right
Architects like designers: IME, yes

Conceptual integrity

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

Page 255

One mental model

Ease of use = functionality / conceptual complexity

Neither function nor simplicity alone define a "good design"
3D modeling: Very complex, but larger functionality
Text editor: Low functionality, very low complexity

Simplicity and straightforwardness proceed from conceptual integrity.

Page 44

Conceptual integrity is the most important consideration in system design.

Page 42

Better to have consistent design than more features
iPhone 1

...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

"Ubiquitous language"

How?

Smart division of labor

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

Page 44

Surgical team: Builder does nothing but build, has big staff to do everything else
Split architect/implementor
Not mono-think, but not conflict-think

Architect/designer

The architect… is the user's agent. It is [their] 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 Cathedral 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

Both challenging/fun
Architecture supports many implementations

The architect must always be prepared to show an implementation for any feature [they] describe, but [they] must not attempt to dictate the implementation.

Page 62

Ongoing cooperative effort, high communication

Also reduces communication channels! Architect to each person.
Divide and conquer large systems, sub-system architects.
Democratic architecture is mud

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

Either can be boss, as long as one is.

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

Author, "The Art of Computer Programming"
"Father of analysis of algorithms"

Larry Garfield

@Crell

Director of Developer Experience Platform.sh

Idea to Cloud Hosting

Stalk us at @PlatformSH

Software Management Lessonsfrom the 1960s