Embed Size (px)
Citation preview
Key Papers in Computer Science
Software Engineering
Yuriy Arbitman
the mythical man-month
Essays on Software Engineering
Frederick P. Brooks, Jr.
About the AuthorFrederick Phillips Brooks, Jr.
• Born in 1931• Ph.D. in CS from Harvard, 1956• Between 1956 and 1965 worked in IBM, was project manager of IBM’s
System/360 computers and OS/360 development.• In 1964 founded CS Department at the University of North Carolina, chaired it for 20 years.
• In 1999 received the Turing Award “for landmark contributions to computer architecture, operating systems, and software engineering”.
The Book (1)1. The Tar Pit2. The Mythical Man-Month3. The Surgical Team4. Aristocracy, Democracy, and System
Design5. The Second-System Effect6. Passing the Word7. Why Did the Tower of Babel Fail?8. Calling the Shot9. Ten Pounds in a Five-Pound Sack10. The Documentary Hypothesis11. Plan to Throw One Away12. Sharp Tools
The Book (2)13. The Whole and the Parts14. Hatching a Catastrophe15. The Other Face16. No Silver Bullet – Essence and Accident in
Software Engineering17. “No Silver Bullet” Refired18. Propositions of The Mythical Man-Month:
True or False?19. The Mythical Man-Month after 20 years20. Fifty Years of Wonder, Excitement and Joy
(Epilogue)1975 - 1995
The Tar Pit (1)• Large-system programming is a tar pit
in the last decade.• The programming systems product:
A Program
A Programming
Product
A Programming
System
A Programming
System Product
1
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Tar Pit (2)
A Program
A Programming Product:•can be run, tested, repaired and extended by anybody•general enough•well documented
A Programming System:
•collection of interacting programs•precisely defined interfaces between individual programs•comply with resource limitations•all combinations tested
A Programming System Product:
both Programming System and Programming Product
x3
x3
1
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Tar Pit (3)• The joys of the craft:
– Making things– Making things that are useful to others– The fascination of fashioning complex
puzzle-like objects– Always learning– Such a tractable medium
• The woes of the craft:– Adjusting to the requirement of perfection– Other people tell you what to do– Worse: must use others’ programs!
1
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Tar Pit (4)• The woes of the craft (cont.):
– Bugs!!!– Bugs get harder as testing progresses– The product gets obsolete upon or even
before completion
1
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Mythical Man-Month (1)• Most software projects are late. Why?
– Assumption that all will go well led the schedule plan
– Confuse effort with progress: men and months are NOT interchangeable!
– Software managers tend to please their managers and because of uncertainty of programmers’ time estimates, plan the schedule poorly [as a discipline we lack estimating data].
– Poor monitoring of project progress– Natural response to schedule slippage is
adding manpower, which makes matters worse.
11
2
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Mythical Man-Month (2)• Optimism:
– All programmers are optimists, believing in happy endings and fairy god-mothers.
– Because programming tasks are usually chained end-to-end, the probability that each will go well is very small.
• Man-month:
– Cost vary as a product: men · months.
– Progress does not: communication overhead!
– Overhead: intercommunication and training.
11
2
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Mythical Man-Month (3)• Different projects types:
Men
Mon
ths
Perfectly partitionable task
Men
Mon
ths
Unpartitionable task
Men
Mon
ths
Partitionable task requiring communication Task with complex interrelationships
Men
Mon
ths
11
2
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Mythical Man-Month (4)• Proposes a successfull rule of thumb:
– 1/3 planning– 1/6 coding– 1/4 component test and early system test– 1/4 system test, all components in hand
• Gutless estimating, or: an omelette example
• Regenerative schedule disaster:– An example– Brook’s Law: Adding manpower to a
late software project makes it later.
11
2
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Surgical Team (1)• The problem: productivity varies hugely
between good programmers and poor ones.• Mill’s proposal: divide large job into
segments, each tackled by a surgical team:– The surgeon. The chief programmer. Defines
spec, designs, codes, tests, documents. The boss.
– The copilot. Less experienced, no responsibility for code.
– The administrator. Handles money, people, space, machines. May be part-time (serve two teams).
– The editor. Improves and perfects the
11
22
3
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Surgical Team (2)documentation produced by the surgeon.
– Two secretaries. One for the administrator and one for the editor.
– The program clerk. Responsible for maintaining all the technical records of the team in a programming-product indexed library.
– The toolsmith . The system manager of the team.
– The tester. Responsible for producing or gathering the test-cases. “The adversary”.
– The language lawyer. Master of the used programming language. Can serve two or three teams [surgeons].
11
22
3
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Surgical Team (3)11
22
3
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Surgeon
Co-pilot
Programming clerk
Toolsmith
Tester
Language lawyer
Administrator
Secretary
Editor
Secretary
Aristocracy, Democracy and System Design• Conceptual integrity is the most important
consideration in system design.– The ratio of function to conceptual complexity
[user-side] is the ultimate test of system design. Measures ease of use, valid over both simple and difficult users.
– Simplicity is not enough. Straightforwardness is required.
– To achieve it, a design must proceed from one mind (or small group of agreeing minds).
• Aristocracy vs. Democracy [Architecture vs. Implementation]:– Blaauw: “Where architecture tells what
happens, implementation tells how it is made to happen”.
– This separation is very important
11
22
33
4
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Second-System Effect (1)• An architect's first work is apt to be spare
and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint.
• As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used “next time”. Sooner or later the first system is finished, and the architect, with firm, confidence and a demonstrated mastery of that class of systems, is ready to build a second system.
11
22
33
44
5
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Second-System Effect (2)• This second is the most dangerous
system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.
• The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.
11
22
33
44
5
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Second-System Effect (3)• Solutions:
– Obviously, an architect cannot skip his second system
– He must be conscious of the dangers, avoiding functional ornamenation and extrapolation of functionality.
– Brooks advises to assign each little function a value, like: capability x is worth not more than m bytes of memory and n microseconds per invocation.
– Project manager can avoid the danger by insisting on a senior architect who designed at least two systems.
11
22
33
44
5
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Second-System Effect (4)– An architect can successfully influence
implementation:• creative responsibility is builder’s, the architect
only suggests• don’t look for credit while suggesting
improvements• listen to builder’s suggestions
• Windows NT as a 1990’s example
11
22
33
44
5
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Passing the Word (1)• The problem: How do we [the manager]
ensure that everyone understand and implement the architects’ decisions?How a group of 10 architects achieve conceptual integrity in a system being built by 1000 men?
• Solutions:– Written specification – the manual:
necessary tool; includes dated versions.– Simulator or previous version may serve as
a formal definition. [Advantages, disadvantages]
11
22
33
44
55
6
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Passing the Word (2)– Meetings - two levels:
• Weekly half-day conference: architects, official representative(s) of implementers, market planners, chief architect presides. The emphasis is on creativity, rather than merely decision.
• Annual / half-year session of two weeks (held just before major freeze dates for the manual). Include also managers of programming. System project manager presides.
All decisions are distibuted immediately after the meetings.
– Telephone log of questions from implementers to the architects, distributed each week to everybody.
– Tests!!!
11
22
33
44
55
6
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Passing the Word (3)– Even in large teams writing must be done
by no more than two people– Formal vs. prose definition: standard and
derivative.
11
22
33
44
55
6
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Why Did the Tower of Babel Fail? (1)• The moral: clear mission, enough
manpower, good materials, enough time and adequate technology DO NOT suffice for a project to succeed. In this case: lack of communication and its consequent, organization.
• Bad communication in software projects are the root of all evil.
• How shall teams communicate with each other? In as many ways as possible:– Informally,
11
22
33
44
55
66
7
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Why Did the Tower of Babel Fail? (2)– Meetings,– and by maintaining a formal project workbook.
• The project workbook:– Not a separate document, but rather a structure
of such.– Includes objectives, external specs, interfaces
specs, technical standards, internal specs and administrative memoranda.
– Brooks describes a detailed fashion of managing and defining the workbook.
– Today it is much easier to develop a satisfiable mechanism for managing such workbook.
– Totally public / structured publicity (argument with Parnas)
11
22
33
44
55
66
7
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Why Did the Tower of Babel Fail? (3)• The essentials of tree-like
programming organization:– a mission– a producer– a technical director (architect)– a schedule– a division of labor– interface definitions among the parts
• Brooks stresses the distinction between the producer and the technical director:
11
22
33
44
55
66
7
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Why Did the Tower of Babel Fail? (4)• The producer:
– assembles the team– divides the work– establishes the schedule– takes care of the necessary resources– establishes the pattern of communication
and reporting within the team– ensures the schedule is met
• The technical director:– Resposible for the design– Provides conceptual integrity– Invent solutions for problems that arise
11
22
33
44
55
66
7
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Why Did the Tower of Babel Fail? (5)• Possible relations between the two:
1. The producer and the technical director may be the same man:– Works with very small teams, 3-6
programmers.– In larger projects will not work: a man with
the needed talents is rarely found, each role is a full-time job.
2. The producer is the boss, the director his right-hand man:– Difficulty: establishing the director’s
authority– This solution is rarely tried
11
22
33
44
55
66
7
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Why Did the Tower of Babel Fail? (6)3. The director is the boss, the producer his
right-hand man:– Best for small teams (as discussed in “The
Surgical Team” chapter)
11
22
33
44
55
66
7
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Calling the Shot• How to estimate the expected time and
effort it will take to build a system?– To estimate only the coding portion and apply
the ratios may lead to ridiculous results.– Nanus and Farr’s study:
effort = constant X (number of instructions)1.5
– Portman’s data: only 50% of working week was realized as actual programming and debugging time (meetings, unrelated jobs, paperwork, etc.).
– There are big differences in productivity related to the compexity of the task:• Operating systems, compilers, normal batch
application programs – factor of 3 between each, respectively.
11
22
33
44
55
66
77
8
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Ten Pounds in a Five-Pound Sack• Program space as cost – much less
relevant today– Resident size– Disk accesses
• More function means more space, speed being held constant.
• Time-space trade-off
11
22
33
44
55
66
77
88
9
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Documentary Hypothesis (1)• The hypothesis: Amid a wash of paper, a
small number of documents become the critical pivots around which every project's management revolves. These are the manager's chief personal tools.
• Brooks suggests the critical documents are:– Objectives– Specifications (the last finished document!)– Schedule– Budget– Organization chart
11
22
33
44
55
66
77
88
99
10
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Documentary Hypothesis (2)– Space allocations– Estimate, forecast, prices:
Forecast
Estimate
Prices
• The similarity to university department: as to any management task.
• Conway’s Law: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations”.
11
22
33
44
55
66
77
88
99
10
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
The Documentary Hypothesis (3)• Why have formal documents?
– writing down decisions is essential (focuses thought and crystallizes discussion)
– the documents will communicate the decisions to others
– database and checklist for the manager– only a small part of a technical project
manager's time (20%) is spent on tasks where he needs information from outside his head
11
22
33
44
55
66
77
88
99
10
1111
1122
1133
1144
1155
1166
1177
1188
1199
2200
Plan to Throw One Away (1)• In most projects, the first system built
is barely usable. It may be:– too slow– too big– awkward to use– or all three
• The management question is not whether to build a pilot system and throw it away, but whether to deliver the throwaway to customers.
11
22
33
44
55
66
77
88
99
1100
11
1122
1133
1144
1155
1166
1177
1188
1199
2200
Plan to Throw One Away (2)• Delivering that throwaway buys time,
but…:– agony for the user– distraction for the builders while they do
the redesign– bad reputation for the product that the best
redesign will find hard to live down
• So: be prepared for a change as a way of life.
• Plan the system for change: – careful modularization– extensive subroutining
11
22
33
44
55
66
77
88
99
1100
11
1122
1133
1144
1155
1166
1177
1188
1199
2200
Plan to Throw One Away (3)– precise and complete definition of
intermodule interfaces– complete documentation of these– quantization of change: numbered versions
and clear policy regarding versions’ releases.
• Plan the organization for change:– Keep managers and technical people as
interchangeable as their talents allow: job titles, dual ladder of advancement, corresponding salary scales, corresponding prestige, “reassignment” vs. “promotion”
11
22
33
44
55
66
77
88
99
1100
11
1122
1133
1144
1155
1166
1177
1188
1199
2200
Plan to Throw One Away (4)• Maintenance:
– Total cost is 40% or more of the development, but strongly affected by the number of users.
Bug occurance as a function of release age
Months since installation
Bu
gs
fou
nd
per
mon
th
– The fundamental problem: fixing a defect has a 20%-50% chance of introducing another. So the whole process is “two steps forward and one step back”.
11
22
33
44
55
66
77
88
99
1100
11
1122
1133
1144
1155
1166
1177
1188
1199
2200
Plan to Throw One Away (5)• “One step forward and one step back”:
– Number of modules increase linearly, but number of modules affected increase exponentially.
– Less and less effort is spent to fix initial design flaws, more and more to fix previous fixes.
• Today: beta version (vs. alpha version)
11
22
33
44
55
66
77
88
99
1100
11
1122
1133
1144
1155
1166
1177
1188
1199
2200
Sharp Tools - Skipped
11
22
33
44
55
66
77
88
99
1100
1111
12
1133
1144
1155
1166
1177
1188
1199
2200
The Whole and the Parts• Many failures origin in poor definition of
requirements• Long before implementation, specification
must be tested for completeness and clarity.• Top-down design – the advantages• Structured programming (today: OOP?)• Debugging:
– Debug each component separately at first– Don’t follow the “documented bug” approach– White-box testing by using dummy components– Add one component at a time– Plan the debugging part carefully
11
22
33
44
55
66
77
88
99
1100
1111
1122
13
1144
1155
1166
1177
1188
1199
2200
Hatching a Catastrophe (1)• “How does a project get to be a year late?
• Day-by-day slippage is harder to recognize, harder to prevent, harder to make up.
• Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. Counterexamples:– Coding is “90% finished” for half of the total
coding time– Debugging is “99% complete” most of the time
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
14
1155
1166
1177
1188
1199
2200
…One day at a time.”
Hatching a Catastrophe (2)• Concreteness in milestones is more
important than easy verifiability by the boss
• How to cope with one-day slippages?– Prepare critical-path schedule
• “Under the rug”-problem. Solutions:– Reducing the role conflict: 1. listen till the end.
2. distinguish between status-review and problem-action meetings.
– Yanking the rug off: periodical review of milestones document (incl. actual dates).
• Keeping actual vs. estimated dates is handy
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
14
1155
1166
1177
1188
1199
2200
Hatching a Catastrophe (3)• PERT chart = critical path chart,
including milestones.• Plans and Controls team (1-3 men in
large project) – reported by Brooks to be very successfull.
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
14
1155
1166
1177
1188
1199
2200
The Other Face (1)• One face: a message from a man to a
machine.• The other face: a message from
human to human!1. To use a program:
– Purpose– Environment– Inputs domain and range– Functions realized and algorithms used– I/O formats– Operating instructions
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
15
1166
1177
1188
1199
2200
The Other Face (2)– Options– Running time– Accuracy and checking3-4 pages, most need to be drafted before
writingthe program
2. To modify a program, clear and sharp overview of the internal structure is needed:
– flow chart– complete algorithms descriptions / reference– all files layout
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
15
1166
1177
1188
1199
2200
The Other Face (3)– design overview and major changes
history and motivations• Flow charts: obsolete! (at most one
page per program)• Self documenting programs:
– The problem: synchronization between code and documentation.
– The solution: to incorporate the documentation in the source program:• Labels, names, spaces,… (good
programming )• Pointers to books [documentation]• Purpose: tell why rather than how things are.
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
15
1166
1177
1188
1199
2200
No Silver Bullet – Essence and Accident
in Software Engineering (1)• “There is no single development, in either
technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity” (1986).
• Silver bullet: a way to defeat werewolves.– Generally [in folklore]: any straightforward
solution perceived to have extreme effectiveness.
• Compares software to hardware:– The anomality is not that software progress is so
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
16
1177
1188
1199
2200
NSB (2)– slow, but that computer hardware
progress is so fast.• Essence—the difficulties inherent in
the nature of the software• Accidents—those difficulties that
today attend its production but that are not inherent [but incidental].
• Essence:– Complexity – Conformity– Changeability– Invisibility
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
16
1177
1188
1199
2200
NSB (3)• Complexity
– enormous number of states (orders of magnitude more than in hardware), so conceiving, describing and testing is hard
– increases non-linearly with its size– introduces a lot of difficulties:
• communication among team members• enumerating (much less understanding) of
all possible states of the program• management problems:
– conceptual integrity is hard to achieve– learning curve: personnel turnover becomes
disaster
• others
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
16
1177
1188
1199
2200
NSB (4)• Conformity
– Physics example: looking for simplicity in complex structures
– Software: the complexity is arbitrary, forced by existing systems to which the interfaces must conform.• cannot be simplyfied by any redesign!
• Changeability– Software is constantly under pressure for
change, partly because it can be changed more easily than a building.
– Two processes are at work:
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
16
1177
1188
1199
2200
NSB (5)• Demand for extended function (a result of
success)• Suitability for a new hardware is needed
• Invisibility– Unlike other disciplines, where geometric
abstractions serve as a powerful tool, software is not inherently embedded in space
– Several general directed graphs, superimposed one upon another appear while trying to create a representation• the graphs are nor planar neither hierarchical
• What helped to overcome some of accidental difficulties in the past?
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
16
1177
1188
1199
2200
NSB (6)– High-level languages– Unified programming environments
• Hopes for the silver:– OOP:
• Hierarchical• Data hidingHelps in design, but do not solve design
complexityproblem
– AI (expert systems)• May be very useful
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
16
1177
1188
1199
2200
NSB (7)– “Automatic” programming: generation of
a program from problem specification• Used successfully for very specific tasks
(differential equations,…)• Hard to imagine having a general solution
– Graphical programming:• No hope, for software is difficult to visualize
– Program verification• Might reduce the program-testing load, not
eliminate it• A lot of work• Can establish that a program meet its
specification. But the hardest part is to get such complete and consistent specification!
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
16
1177
1188
1199
2200
NSB (8)– Better workstations, environments and
tools• are welcomed, but magical enhacements
cannot be expected
– Buy vs. Build • Discusses the process of wide-spread use of
software “today” compared to 60-s, adopting procedures to existing software
– Requirements refinement and rapid prototyping• “The hardest single part of building a
software system is deciding precisely what to build”
• Thus, rapid prototyping tools are one of the most promising efforts that attack the essence of software development problem.
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
16
1177
1188
1199
2200
NSB (9)– Incremental development
• Write vs. Build• Build vs. Grow (top-down design, stubs…)
– Great designers• “The difference between the great and the
average approach an order of magnitude”• Gives hints as to how to grow great
designers
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
16
1177
1188
1199
2200
“NSB” Refired - Skipped11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
17
1188
1199
2200
Propositions of The M-MM –True or False?
Considered in the previous slides
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
18
1199
2200
The M-MM after 20 years (1)Answers questions like: What do you now
think was wrong when written? What is nowobsolete? What is really new in the softwareengineering world?
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
19
2200
• What was right and still is:– Conceptual integrity is the more important
factor in ease of use [There are other factors. Consider Macintosh vs. MS-DOS].It is the central question addresses by M-MM and is central to product quality.
The M-MM after 20 years (2)11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
19
2200
– The architect’s central role– The parallel between the Second-System
Effect and mass-market software products– It is important to define the user set
(Who they are? What they need? What they think they need? What they want?). Write down explicit guesses for the attributes of the user set and their frequencies.
• The triumph of the WIMP interface– Windows, Icons, Menus, Pointing interface– Predicts it to become obsolete within a
generation
The M-MM after 20 years (3)11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
19
2200
• “Plan to throw one away” is wrong:– Not too radical, but too simplistic– Implicitly assumes the waterfall model:
Plan
System Test
Code
Field Support
Component Test
It is wrong because:• Assumes “one-shot”, assumes realization
mistakes only
There must be upstream movement.– Better approach is Incremental-Build
Model (already mentioned in NSB)
• Nightly Build approach– May be too radical for huge systems
The M-MM after 20 years (4)11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
19
2200
• Incremental build and rapid prototyping are very close
• Information hiding vs. full publicity– Both can lead to disasters
• Barry Boehm model and data:– Cost-optimum schedule time to first
shipment is
• Refined Brooks Law – By Abdel-Hamid and Madnick– Adding more people to a late project
always makes it more costly, but it does not always cause it to be completed later
35.2 MMl
The M-MM after 20 years (5)11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
19
2200
• Why speak about management rather than technical issues?
– People are everything• Factor of four compared to the next
largest one
– Importance of delegating power downwards in the organizational structure• Autonomous teams [sub-units], having its
own resources and schedules
Fifty Years of Wonder, Excitement and Joy
11
22
33
44
55
66
77
88
99
1100
1111
1122
1133
1144
1155
1166
1177
1188
1199
20
Skipped
The Cathedral and the Bazaar (1)
Written by Eric Steven Raymond (ESR)Central “lessons”:1. Every good work of software starts by
scratching a developer’s personal itch.2. Good programmers know what to write.
Great ones know what to rewrite (and reuse).
3. “Plan to throw one away; you will, anyhow” (Brooks).
4. If you have the right attitude, interesting problems will find you.
The Cathedral and the Bazaar (2)
5. When you lose interest in a program, your last duty is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone [Given enough eyeballs, all bugs are shallow – Linus’s Law].
The Cathedral and the Bazaar (3)
9. Smart data structures and dumb code works a lot better than the other way around.
10.If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
11.The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12.Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
The Cathedral and the Bazaar (4)
13.“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away” – Antoine de Saint-Exupéry.
14.Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15.When writing gateway software of any kind, take pains to disturb the data stream as little as possible – and never throw away information unless the recipient forces you to!
The Cathedral and the Bazaar (5)
16.When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17.A security system is only as secure as its secret. Beware of pseudo-secrets.
18.To solve an interesting problem, start by finding a problem that is interesting to you.
19.Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
