Platform.sh
Software Management Lessons from the 1960s
Presented by Larry Garfield (@Crell)
@Crell
- Director of DX, Platform.sh
- PHP-FIG Core Committee
- Drupal 8 Web Services Lead
implements Huggable
IBM System/360
Legacy
- 8-bit byte
- Byte-addressable memory
- EBCDIC
Lives on as IBM zSeries
Lead team
Lead architect
Lead manager
"The Mythical Man Month"
1975
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
Tasks are not parallelizable
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
(Depending on swim lanes,
and how early)
Amdahl's law
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
What should we learn from this?
Why are estimates always wrong?
Programming Systems Product
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
—Nanus and Farr, Page 89
| 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
Lines of code in Symfony 4: 511369
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 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
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
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?
Wrong!
Agile?
(Credit: http://comunidad.iebschool.com/)
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 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
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 [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
- 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
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.
Larry Garfield
@Crell
Director of Developer Experience Platform.sh
Idea to Cloud Hosting
Stalk us at @PlatformSH