THE MYTHICAL

MAN-MONTH
Frederick P Brooks Jr.

Presented By,
Merin Scaria
 CONTENTS
 The Tar Pit
 The Mythical Man-Month
 The Surgical Team
 Aristocracy, Democracy, and System Design
 The Second-System Effect
 Passing the Word
 Why Did the Tower of Babel Fail?
 Calling the Shot
 Ten Pounds in a Five-Pound Sack
 The Documentary Hypothesis
 Plan to Throw One Away
 The Whole & the Parts
 Hatching a catastrophe.
 The Other Face
 No Silver Bullets
1
2
THE TAR-PIT
3
A Programming System:
4
•collection of interacting
5 programs
A Program
6 •precisely defined
x3 interfaces between
7
individual programs
8 •comply with resource
9 limitations
•all combinations tested
10 x3
11
12
13
14 A Programming
A Programming Product:
System Product:
15 •can be run, tested,
16 repaired and extended by both Programming
anybody System and
17
•general enough Programming
18 •well documented Product
19
20
1
2
CONTINUED…
3
4 • The joys of the craft:
5 – Making things that are useful to others
6 – The fascination of fashioning complex puzzle-like objects
7
– Always learning
8
– Such a tractable medium
9
10
• The woes of the craft:
11 – Adjusting to the requirement of perfection
12 – Other people tell you what to do
13 – Worse: must use others’ programs!
14 – Bugs!!!
15
– Bugs get harder as testing progresses
16
– The product gets obsolete upon or even before completion
17
18
19
20
1
2
THE MYTHICAL MAN-MONTH
3  Most software projects are late. Why?
4 – Estimation techniques are poor-all goes well assumption.
5 – Confuse effort with progress
6 – Poor monitoring of project progress
7
– Natural response to schedule slippage is adding manpower, which
8
makes matters worse.
9
• Optimism:
10
– Book-author’s mind-pen and paper-faulty ideas & physical media
11
limitations.
12
13
– In programming-media is good-optimistic-idea from mind-faulty
14
ideas-error.
15 • Man-month:
16 – Cost vary as a product: of men & months.
17 – Progress does not: communication overhead!
18 – Overhead: intercommunication and training.
19
20
1
2
CONTINUED…
3
• Different projects types:
4
Perfectly partitionable task Unpartitionable task
5
6
Months

Months
7
8
9
10
11
Men Men
12
13 Partitionable task requiring communication Task with complex interrelationships
14
15
Months

16
Months
17
18
19
20 Men Men
1
2
CONTINUED…
3
4 • Suppose a task is estimated at 12 man-months and assigned to 3 men
5 for 4 months. Suppose the first milepost is not reached until 2 months
6 have elapsed.
7
8
9
10
11
12
13
14 • Suppose that at 2 months, we achieve milestone A. We must deliver
15 on time.
16 • What can we do?
17
18
19
20
1
2
CONTINUED…
3
• Let’s say we add 2 people at month 2.
4 – Must train them – assume this takes 1 month and requires 1 of the
other 3 people.
5
6
– During month 3:
7
• 3 person-months of training work
8 • 2 person-months of actual work.
9 – Still have 9-2=7 person-months of work, but only 1 month left!
10 – So what do we do? Add more people…and have a later delivery.
11 • Brooks’s law: Adding people to a late software project makes it
12 later.
13
14
15
16
17
18
19
20
1
2
THE SURGICAL TEAM
3 • The problem: productivity varies hugely between good programmers
4 and poor ones.
5 • Mill’s proposal: divide large job into segments, each tackled by a
6 surgical team:
7 – The surgeon. The chief programmer. Defines spec, designs, codes,
8 tests, documents. The boss.
9 – The copilot. Less experienced, no responsibility for code, insurance.
10 – The administrator. Handles money, people, space, machines. May be
11 part-time (serve two teams).
12
– The editor. Improves and perfects the documentation.
13
– Two secretaries. One for the administrator and one for the editor.
14
– The program clerk. maintains all the technical records of the team.
15
16 – The toolsmith- The system manager of the team.
17 – The tester. Responsible for producing or gathering the test-cases.
18 – The language lawyer. Master of the used programming language.
19
20
1
2
THE SURGICAL TEAM
3
4
Surgeon
5
6
7
Administrator Co-pilot
8
9
10 Secretary Programming
11 clerk
12
13 Toolsmith
14
Editor
15 Tester
16
Secretary
17
Language
18
lawyer
19
20
ARISTOCRACY, DEMOCRACY AND
1
2
3
4
SYSTEM DESIGN
5 • Conceptual integrity is the most important consideration in system
design.
6
– Why?
7
– Ease of use.
8
– To achieve it, a design must proceed from one mind (or small group
9 of agreeing minds).
10 • Schedule pressure dictate system building need many hands.
11 • 2 techniques to resolve it:
12 - careful division of labor between architecture & implementation
13 - use efficient programming implementation teams.
14 • Aristocracy vs. Democracy [Architecture vs. Implementation]:
15 – Blaauw: “Where architecture tells what happens, implementation
16
tells how it is made to happen”.
– This separation is very important.
17
– E.g. clock
18
19
20
1
2
The Second-System Effect (1)
3 • An architect's first work is apt to be spare and
4
5 clean. He knows he doesn't know what he's
6 doing, so he does it carefully and with great
7
8 restraint.
9
10
• As he designs the first work, frill after frill and
11 embellishment after embellishment occur to him.
12
13
These get stored away to be used “next time”.
14 Sooner or later the first system is finished, and
15
16 the architect, with firm, confidence and a
17 demonstrated mastery of that class of systems, is
18
19 ready to build a second system.
20
1
2
The Second-System Effect (2)
3 • This second is the most dangerous system a man
4
5 ever designs. When he does his third and later
6 ones, his prior experiences will confirm each
7
8 other as to the general characteristics of such
9
systems, and their differences will identify those
10
11 parts of his experience that are particular and
12
13
not generalizable.
14 • The general tendency is to over-design the
15
16 second system, using all the ideas and frills that
17 were cautiously sidetracked on the first one.
18
19
20
1
2
The Second-System Effect (3)
3 • Solutions:
4
5 – Obviously, an architect cannot skip his second
6 system 
7
8
– He must be conscious of the dangers, avoiding
9 functional ornamenation and extrapolation of
10 functionality.
11
12 – Brooks advises to assign each little function a
13 value, like: capability x is worth not more than m
14
bytes of memory and n microseconds per
15
16
invocation.
17 – Project manager can avoid the danger by insisting
18
on a senior architect who designed at least two
19
20 systems.
1
2
The Second-System Effect (4)
3 – An architect can successfully influence
4
implementation:
5
6
• creative responsibility is builder’s, the architect only
7 suggests
8 • don’t look for credit while suggesting improvements
9
• listen to builder’s suggestions
10
11 • Windows NT as a 1990’s example
12
13
14
15
16
17
18
19
20
1
2
Passing the Word (1)
3 • The problem: How do we [the manager]
4
5 ensure that everyone understand and
6 implement the architects’ decisions?
7
8 How a group of 10 architects achieve
9
conceptual integrity in a system being built
10
11 by 1000 men?
12
13
• Solutions:
14
– Written specification – the manual: necessary tool;
15
16
includes dated versions.
17 – Simulator or previous version may serve as a
18
19
formal definition. [Advantages, disadvantages]
20
1
2
Passing the Word (2)
3 – Meetings - two levels:
4
• Weekly half-day conference: architects, official
5
6
representative(s) of implementers, market planners,
7 chief architect presides. The emphasis is on
8 creativity, rather than merely decision.
9 • Annual / half-year session of two weeks (held just
10
before major freeze dates for the manual). Include
11
12
also managers of programming. System project
13 manager presides.
14 All decisions are distibuted immediately after
15
16
the meetings.
17 – Telephone log of questions from implementers to the
18
19
architects, distributed each week to everybody.
20 – Tests!!!
1
2
Passing the Word (3)
3 – Even in large teams writing must be done by no
4
more than two people
5
6 – Formal vs. prose definition: standard and
7
derivative.
8
9
10
11
12
13
14
15
16
17
18
19
20
1
2
Why Did the Tower of Babel Fail? (1)
3
4
• The moral: clear mission, enough
5 manpower, good materials, enough time
6
7
and adequate technology DO NOT suffice
8 for a project to succeed. In this case: lack of
9
10
communication and its consequent,
11 organization.
12
13 • Bad communication in software projects are
14
15
the root of all evil.
16
• How shall teams communicate with each
17
18 other? In as many ways as possible:
19
20
– Informally,
1
2
Why Did the Tower of Babel Fail? (2)
3 – Meetings,
4
5
– and by maintaining a formal project workbook.
6 • The project workbook:
7
8
– Not a separate document, but rather a structure of such.
9 – Includes objectives, external specs, interfaces specs,
10 technical standards, internal specs and administrative
11 memoranda.
12
13
– Brooks describes a detailed fashion of managing and
14 defining the workbook.
15 – Today it is much easier to develop a satisfiable
16 mechanism for managing such workbook.
17
18
– Totally public / structured publicity (argument with
19 Parnas)
20
1
2
Why Did the Tower of Babel Fail? (3)
3
4
• The essentials of tree-like programming
5 organization:
6
7
– a mission
8 – a producer
9
10 – a technical director (architect)
11
12
– a schedule
13 – a division of labor
14
15
– interface definitions among the parts
16
17
• Brooks stresses the distinction between the
18 producer and the technical director:
19
20
1
2
Why Did the Tower of Babel Fail? (4)
3
4
• The producer:
5 – assembles the team
6
7
– divides the work
8 – establishes the schedule
9
10
– takes care of the necessary resources
11 – establishes the pattern of communication and
12 reporting within the team
13
14 – ensures the schedule is met
15
16
• The technical director:
17 – Resposible for the design
18
19
– Provides conceptual integrity
20 – Invent solutions for problems that arise
1
2
Why Did the Tower of Babel Fail? (5)
3
4
• Possible relations between the two:
5 1. The producer and the technical director may
6
7
be the same man:
8 – Works with very small teams, 3-6 programmers.
9 – In larger projects will not work: a man with the
10
needed talents is rarely found, each role is a full-
11
12
time job.
13 2. The producer is the boss, the director his right-
14
hand man:
15
16 – Difficulty: establishing the director’s authority
17 – This solution is rarely tried
18
19
20
1
2
Why Did the Tower of Babel Fail? (6)
3
3. The director is the boss, the producer his right-
4
5
hand man:
6 – Best for small teams (as discussed in “The Surgical
7 Team” chapter)
8
9
10
11
12
13
14
15
16
17
18
19
20
1
2
Calling the Shot
3
• How to estimate the expected time and
4
5 effort it will take to build a system?
6 – To estimate only the coding portion and apply the
7 ratios may lead to ridiculous results.
8
9
– Nanus and Farr’s study:
10 effort = constant X (number of instructions)1.5
11 – Portman’s data: only 50% of working week was
12 realized as actual programming and debugging
13
time (meetings, unrelated jobs, paperwork, etc.).
14
15
– There are big differences in productivity related to
16 the compexity of the task:
17 • Operating systems, compilers, normal batch
18 application programs – factor of 3 between each,
19 respectively.
20
1
2
Ten Pounds in a Five-Pound Sack
3
4
• Program space as cost – much less relevant
5 today
6
7
– Resident size
8 – Disk accesses
9
10 • More function means more space, speed
11
12
being held constant.
13
14
• Time-space trade-off
15
16
17
18
19
20
1
2
The Documentary Hypothesis (1)
3
4
• The hypothesis: Amid a wash of paper, a small
5 number of documents become the critical pivots
6
7
around which every project's management
8 revolves. These are the manager's chief personal
9
10
tools.
11
12
• Brooks suggests the critical documents are:
13 – Objectives
14
15
– Specifications (the last finished document!)
16 – Schedule
17
18 – Budget
19
20
– Organization chart
1
2
The Documentary Hypothesis (2)
3
– Space allocations
4
5 – Estimate, forecast, prices:
6
7 Forecast Estimate
8
9 Prices
10
11 • The similarity to university department: as
12
13
to any management task.
14 • Conway’s Law: “Organizations which design
15
16 systems are constrained to produce systems
17
which are copies of the communication
18
19 structures of these organizations”.
20
1
2
The Documentary Hypothesis (3)
3
4
• Why have formal documents?
5 – writing down decisions is essential (focuses
6
7
thought and crystallizes discussion)
8 – the documents will communicate the decisions
9
to others
10
11 – database and checklist for the manager
12
13
– only a small part of a technical project
14 manager's time (20%) is spent on tasks where he
15 needs information from outside his head
16
17
18
19
20
1
2
Plan to Throw One Away (1)
3
4
• In most projects, the first system built is
5 barely usable. It may be:
6
7
– too slow
8 – too big
9
10 – awkward to use
11
12
– or all three 
13 • The management question is not whether to
14
15 build a pilot system and throw it away, but
16
whether to deliver the throwaway to
17
18 customers.
19
20
1
2
Plan to Throw One Away (2)
3
4
• Delivering that throwaway buys time,
5 but…:
6
7
– agony for the user
8 – distraction for the builders while they do the
9
10
redesign
11 – bad reputation for the product that the best
12
13
redesign will find hard to live down
14
• So: be prepared for a change as a way of life.
15
16 • Plan the system for change:
17
18 – careful modularization
19
– extensive subroutining
20
1
2
Plan to Throw One Away (3)
3
– precise and complete definition of intermodule
4
5
interfaces
6 – complete documentation of these
7
8 – quantization of change: numbered versions and
9 clear policy regarding versions’ releases.
10
11 • Plan the organization for change:
12
13
– Keep managers and technical people as
14 interchangeable as their talents allow: job titles,
15
dual ladder of advancement, corresponding
16
17
salary scales, corresponding prestige,
18 “reassignment” vs. “promotion”
19
20
1
2
Plan to Throw One Away (4)
3 • Maintenance:
4
– Total cost is 40% or more of the development,
5
6 but strongly affected by the number of users.
7 Bug occurance as a function of release age

Bugs found per month

8
9
10
11
12
13
14
15
Months since installation
16 – The fundamental problem: fixing a defect has a
17
20%-50% chance of introducing another. So the
18
19
whole process is “two steps forward and one
20 step back”.
1
2
Plan to Throw One Away (5)
3
4
• “One step forward and one step back”:
5 – Number of modules increase linearly, but
6
7
number of modules affected increase
8 exponentially.
9
– Less and less effort is spent to fix initial design
10
11 flaws, more and more to fix previous fixes.
12
13
• Today: beta version (vs. alpha version)
14
15
16
17
18
19
20
1
2
Sharp Tools - Skipped
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1
2
The Whole and the Parts
3
• Many failures origin in poor definition of
4
5
requirements
6 • Long before implementation, specification must be
7
8
tested for completeness and clarity.
9 • Top-down design – the advantages
10
11 • Structured programming (today: OOP?)
12
• Debugging:
13
14 – Debug each component separately at first
15 – Don’t follow the “documented bug” approach
16
17
– White-box testing by using dummy components
18 – Add one component at a time
19
– Plan the debugging part carefully
20
1
2
Hatching a Catastrophe (1)
3
4
• “How does a project get to be a year late?…One
5 day at a time.”
6
7 • Day-by-day slippage is harder to recognize,
8
9
harder to prevent, harder to make up.
10
11
• Milestones must be concrete, specific,
12 measurable events, defined with knife-edge
13
14
sharpness. Counterexamples:
15 – Coding is “90% finished” for half of the total
16
17
coding time
18 – Debugging is “99% complete” most of the time
19
20
1
2
Hatching a Catastrophe (2)
3
4
• Concreteness in milestones is more
5 important than easy verifiability by the boss
6
7 • How to cope with one-day slippages?
8
9
– Prepare critical-path schedule
10 • “Under the rug”-problem. Solutions:
11
12 – Reducing the role conflict: 1. listen till the end.
13 2. distinguish between status-review and
14
15
problem-action meetings.
16 – Yanking the rug off: periodical review of
17
18
milestones document (incl. actual dates).
19
• Keeping actual vs. estimated dates is handy
20
1
2
Hatching a Catastrophe (3)
3
4
• PERT chart = critical path chart, including
5 milestones.
6
7 • Plans and Controls team (1-3 men in large
8
9
project) – reported by Brooks to be very
10 successfull.
11
12
13
14
15
16
17
18
19
20
1
2
The Other Face (1)
3
4
• One face: a message from a man to a
5 machine.
6
7 • The other face: a message from human to
8
9
human!
10 1. To use a program:
11
12 – Purpose
13
14
– Environment
15 – Inputs domain and range
16
17
– Functions realized and algorithms used
18 – I/O formats
19
20 – Operating instructions
1
2
The Other Face (2)
3
– Options
4
5 – Running time
6
7
– Accuracy and checking
8 3-4 pages, most need to be drafted before writing
9
10 the program
11
12
2. To modify a program, clear and sharp
13 overview of the internal structure is
14
15
needed:
16 – flow chart
17
18 – complete algorithms descriptions / reference
19
– all files layout
20
1
2
The Other Face (3)
3 – design overview and major changes history
4
and motivations
5
6 • Flow charts: obsolete! (at most one page per
7
8
program)
9 • Self documenting programs:
10
11
– The problem: synchronization between code
12 and documentation.
13 – The solution: to incorporate the documentation
14
15
in the source program:
16 • Labels, names, spaces,… (good programming )
17 • Pointers to books [documentation]
18 • Purpose: tell why rather than how things are.
19
20
1 No Silver Bullet – Essence and Accident
2
3 in Software Engineering (1)
4
5 • “There is no single development, in either
6 technology or management technique, which by
7
8 itself promises even one order-of-magnitude
9 improvement within a decade in productivity, in
10
11
reliability, in simplicity” (1986).
12 • Silver bullet: a way to defeat werewolves.
13
14 – Generally [in folklore]: any straightforward
15 solution perceived to have extreme effectiveness.
16
17 • Compares software to hardware:
18 – The anomality is not that software progress is so
19
20
1
2
NSB (2)
3 – slow, but that computer hardware progress is
4
so fast.
5
6 • Essence—the difficulties inherent in the
7
8
nature of the software
9 • Accidents—those difficulties that today
10
11
attend its production but that are not
12 inherent [but incidental].
13
14
• Essence:
15 – Complexity
16
17
– Conformity
18 – Changeability
19
– Invisibility
20
1
2
NSB (3)
3
• Complexity
4
5 – enormous number of states (orders of
6 magnitude more than in hardware), so
7 conceiving, describing and testing is hard
8
9 – increases non-linearly with its size
10 – introduces a lot of difficulties:
11
• communication among team members
12
13 • enumerating (much less understanding) of all
14 possible states of the program
15 • management problems:
16 – conceptual integrity is hard to achieve
17 – learning curve: personnel turnover becomes disaster
18
• others
19
20
1
2
NSB (4)
3
4
• Conformity
5 – Physics example: looking for simplicity in
6
7
complex structures
8 – Software: the complexity is arbitrary, forced
9
by existing systems to which the interfaces
10
11 must conform.
12 • cannot be simplyfied by any redesign!
13
14 • Changeability
15
16
– Software is constantly under pressure for
17 change, partly because it can be changed more
18 easily than a building.
19
20 – Two processes are at work:
1
2
NSB (5)
3 • Demand for extended function (a result of success)
4
5
• Suitability for a new hardware is needed
6
• Invisibility
7
8 – Unlike other disciplines, where geometric
9 abstractions serve as a powerful tool, software
10
11
is not inherently embedded in space
12 – Several general directed graphs,
13
14
superimposed one upon another appear while
15 trying to create a representation
16
• the graphs are nor planar neither hierarchical
17
18 • What helped to overcome some of
19
20
accidental difficulties in the past?
1
2
NSB (6)
3
– High-level languages
4
5 – Unified programming environments
6
7 • Hopes for the silver:
8
– OOP:
9
10 • Hierarchical
11 • Data hiding
12
13
Helps in design, but do not solve design complexity
14 problem
15
16
– AI (expert systems)
17 • May be very useful
18
19
20
1
2
NSB (7)
3 – “Automatic” programming: generation of a
4
program from problem specification
5
6 • Used successfully for very specific tasks
7 (differential equations,…)
8 • Hard to imagine having a general solution
9
– Graphical programming:
10
11 • No hope, for software is difficult to visualize
12 – Program verification
13
• Might reduce the program-testing load, not
14
eliminate it
15
16 • A lot of work
17 • Can establish that a program meet its specification.
18 But the hardest part is to get such complete and
19 consistent specification!
20
1
2
NSB (8)
3 – Better workstations, environments and tools
4
• are welcomed, but magical enhacements cannot be
5
6
expected
7 – Buy vs. Build 
8 • Discusses the process of wide-spread use of
9
software “today” compared to 60-s, adopting
10
procedures to existing software
11
12 – Requirements refinement and rapid
13 prototyping
14 • “The hardest single part of building a software system is
15 deciding precisely what to build”
16
17
• Thus, rapid prototyping tools are one of the most
18
promising efforts that attack the essence of software
19
development problem.
20
1
2
NSB (9)
3
– Incremental development
4
5 • Write vs. Build
6 • Build vs. Grow (top-down design, stubs…)
7
8
– Great designers
9 • “The difference between the great and the average
10 approach an order of magnitude”
11
12
• Gives hints as to how to grow great designers
13
14
15
16
17
18
19
20
1
2
“NSB” Refired - Skipped
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1 Propositions of The M-MM –
2
3
True or False?
4
5
6 Considered in the previous slides
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1
2 The M-MM after 20 years (1)
3
4 Answers questions like: What do you now
5
6 think was wrong when written? What is now
7
8 obsolete? What is really new in the software
9
10 engineering world?
11
12 • What was right and still is:
13
14
– Conceptual integrity is the more important
15 factor in ease of use [There are other
16
factors. Consider Macintosh vs. MS-DOS].
17
18 It is the central question addresses by
19 M-MM and is central to product quality.
20
1
2 The M-MM after 20 years (2)
3
4 – The architect’s central role
5
– The parallel between the Second-System
6
7 Effect and mass-market software products
8
9
– It is important to define the user set (Who
10 they are? What they need? What they think
11 they need? What they want?). Write down
12
13
explicit guesses for the attributes of the
14 user set and their frequencies.
15
16 • The triumph of the WIMP interface
17
18
– Windows, Icons, Menus, Pointing interface
19 – Predicts it to become obsolete within a
20
generation
1
2 The M-MM after 20 years (3)
3
4 • “Plan to throw one away” is wrong:
5
6
– Not too radical, but too simplistic
7 – Implicitly assumes the waterfall model:
8
9 ItPlan
is wrong because:
10
11 • Assumes “one-shot”, assumes realization
12 mistakes only
Code
13
14
There must be upstream
Component movement.
Test
15 – Better approach is Incremental-Build Model
16
17
(already mentioned in NSB)System
Test
18
19
• Nightly Build approach Field
Support
20 – May be too radical for huge systems
1
2 The M-MM after 20 years (4)
3
4 • Incremental build and rapid prototyping
5 are very close
6
7 • Information hiding vs. full publicity
8
– Both can lead to disasters
9
10 • Barry Boehm model and data:
11
12
– Cost-optimum schedule time to first shipment
13 is l  2.5  3 MM
14
15
• Refined Brooks Law
16 – By Abdel-Hamid and Madnick
17
18
– Adding more people to a late project always makes it
19 more costly, but it does not always cause it to be
20 completed later
1
2 The M-MM after 20 years (5)
3
4 • Why speak about management rather
5
6
than technical issues?
7 – People are everything
8
9
• Factor of four compared to the next largest one
10 – Importance of delegating power
11
12
downwards in the organizational structure
13 • Autonomous teams [sub-units], having its own
14
resources and schedules
15
16
17
18
19
20
1
2
Fifty Years of Wonder,
3
4
Excitement and Joy
5
6
Skipped
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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.