robert lockyer

22
Robert Lockyer

Upload: elkan

Post on 23-Feb-2016

51 views

Category:

Documents


0 download

DESCRIPTION

Robert Lockyer. Summary. The Tar Pit The Mythical Man Month The Surgical Team Aristocracy, Democracy and System Design Passing the word The Whole and the parts. The Tar Pit. Large systems programming is a tar pit Most emerge with running systems Few meet goals, schedules and budgets - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Robert Lockyer

Robert Lockyer

Page 2: Robert Lockyer

SummaryThe Tar PitThe Mythical Man MonthThe Surgical Team Aristocracy, Democracy and System DesignPassing the wordThe Whole and the parts

Page 3: Robert Lockyer

The Tar PitLarge systems programming is a tar pitMost emerge with running systemsFew meet goals, schedules and budgetsSmall groups seem much more efficientThey only build Programs, not Programming Systems Products

Page 4: Robert Lockyer

AProgram

AProgramming

System

AProgramming

Product

AProgramming

SystemsProduct

3X

3 X

Page 5: Robert Lockyer

The Mythical Man-Month

Cost varies as a function of the number of men and months, progress does not.Men and months are not interchangeable in software development.Men and months are interchangeable only when a task can be partitioned among many workers with no communication among them.

Page 6: Robert Lockyer

Mon

ths

Men

perfectly partitionable task

Page 7: Robert Lockyer

Mon

ths

Men

unpartitionable task

Page 8: Robert Lockyer

Mon

ths

Men

partitionable task requiring communication

Page 9: Robert Lockyer

Mon

ths

Men

task with complex interrelationships

Brooks’s Law: Adding manpower to a late software project makes it later

Page 10: Robert Lockyer

ScheduleRule of thumb

1/3 for design1/6 for coding1/4 for component testing1/4 for system testing

As a discipline we lack estimating data

Page 11: Robert Lockyer

The Surgical TeamThere are major productivity variations between good programmers and poor ones (on the order of 10x)We want to build a system using as few minds as possible, to avoid unnecessary communication and maintain structural coherence.The problem is that large projects require many hands.The solution may lie in how we organize peopleKey is to reduce needed communication

Page 12: Robert Lockyer

Mills’s ProposalThe Surgeon

Chief programmer

The CopilotAlter ego of surgeon, can do any job but less experiencedSurgeon gets final say on all decisions

The AdministratorSurgeon is boss, but shouldn’t be involved in the bureaucratic details

Page 13: Robert Lockyer

Mills’s ProposalThe Program Clerk (automate?)

Keeper of program input/output data

The EditorSurgeon writes docs, editor criticizes, reworks, etc

Two SecretariesAdmin and Editor need one each

Page 14: Robert Lockyer

Mills’s ProposalThe Tool Smith

Builds custom tools and processes for the surgeon

The TesterSurgeons adversary, builds tests based on specs and helps devise test data for debugging

The Language LawyerDelights in the obscurities of a programming languageOne can serve two or three surgeons

Page 15: Robert Lockyer

Problem: How do we maintain conceptual integrity of a project?

Small architecture team alone should alone write all external specifications

Architecture means: Complete and detailed specification of the user interface

Aristocracy, Democracy, and System Design

Page 16: Robert Lockyer

Aristocracy, Democracy, and System Design

The implementers raise three objections:The specs will be too rich in function, will not be practical

The architects will get all the creative fun and shut out the inventiveness of the implementers

The many implementers will have to sit idly by while specifications are written

Page 17: Robert Lockyer

Passing the wordArchitecture specs must not only describe what the user can see, must refrain from describing what the user does not see.Must define what is not prescribed as carefully as what is.“Never go to sea with two chronometers, take one or three”

Always have one definition as standard. All others are subservient.

Page 18: Robert Lockyer

Passing the wordChanges to the manual should be made clear to developers implementing that functionality. Highlight in logbook/wiki whatever system in useImplementers must be able to easily contact architect for clarification. These conversations must be made available to anyone concerned.

Page 19: Robert Lockyer

The Whole and the Parts

o Build plenty of scaffoldingo It’s not unreasonable for there to be half as

much code in scaffolding as there is in producto Add one component at a time

o Laziness temps us to violate it, requires extensive scaffolding, maybe there are no bugs…

o There ARE bugs, so it’s worth building the scaffolding.

Page 20: Robert Lockyer

ReviewThe Tar PitThe Mythical Man MonthThe Surgical Team Aristocracy, Democracy and System DesignPassing the wordThe Whole and the Parts

Page 21: Robert Lockyer

ReferencesThe Mythical Man-Month: Essays on Software Engineering, Frederick P. Brooks, Jr. (University of North Carolina at Chapel Hill) 1986

Wikipedia: IBM System/360http://en.wikipedia.org/wiki/IBM_System/360

Page 22: Robert Lockyer

Questions?