Docstoc

Brooks

Document Sample
Brooks Powered By Docstoc
					Key Papers in Computer Science

      Software Engineering
           Yuriy Arbitman
 the mythical man-month
Essays on Software Engineering

      Frederick P. Brooks, Jr.
          About the Author
                Frederick 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 Pit
2.    The Mythical Man-Month
3.    The Surgical Team
4.    Aristocracy, Democracy, and System Design
5.    The Second-System Effect
6.    Passing the Word
7.    Why Did the Tower of Babel Fail?
8.    Calling the Shot
9.    Ten Pounds in a Five-Pound Sack
10.   The Documentary Hypothesis
11.   Plan to Throw One Away
12.   Sharp Tools
                 The Book (2)
13.   The Whole and the Parts
14.   Hatching a Catastrophe
15.   The Other Face
16.   No Silver Bullet – Essence and Accident in
      Software Engineering
17.   ―No Silver Bullet‖ Refired
18.   Propositions of The Mythical Man-Month: True or
      False?
19.   The Mythical Man-Month after 20 years
20.   Fifty Years of Wonder, Excitement and Joy
      (Epilogue)
                                  1975 - 1995
1
2
                The Tar Pit (1)
3    • Large-system programming is a tar pit in
4
5      the last decade.
6
7
     • The programming systems product:
8
9                                A
10             A Program    Programming
11                             System

12
13
14
15
16                  A             A
              Programming    Programming
17                          System Product
                 Product
18
19
20
1
2
               The Tar Pit (2)
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:
15
                                         System Product:
     •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
                 The Tar Pit (3)
3    • The joys of the craft:
4
5      – Making things
6
7
       – Making things that are useful to others
8      – The fascination of fashioning complex puzzle-
9
         like objects
10
11     – Always learning
12
13
       – Such a tractable medium
14
15
     • The woes of the craft:
16     – Adjusting to the requirement of perfection
17
18
       – Other people tell you what to do
19     – Worse: must use others’ programs!
20
1
2
                 The Tar Pit (4)
3    • The woes of the craft (cont.):
4
5      – Bugs!!!
6
7
       – Bugs get harder as testing progresses
8      – The product gets obsolete upon or even before
9
         completion
10
11
12
13
14
15
16
17
18
19
20
1
2
      The Mythical Man-Month (1)
3    • Most software projects are late. Why?
4
5      – Assumption that all will go well led the
6        schedule plan
7
8      – Confuse effort with progress: men and months
9        are NOT interchangeable!
10
11     – Software managers tend to please their
12       managers and because of uncertainty of
13
         programmers’ time estimates, plan the schedule
14
15       poorly [as a discipline we lack estimating data].
16
       – Poor monitoring of project progress
17
18     – Natural response to schedule slippage is adding
19       manpower, which makes matters worse.
20
1
2
      The Mythical Man-Month (2)
3    • Optimism:
4
5      – All programmers are optimists, believing in
6        happy endings and fairy god-mothers.
7
8      – Because programming tasks are usually chained
9        end-to-end, the probability that each will go
10
11
         well is very small.
12   • Man-month:
13
14     – Cost vary as a product: men· months.
15
16
       – Progress does not: communication overhead!
17     – Overhead: intercommunication and training.
18
19
20
1
2
                The Mythical Man-Month (3)
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
      The Mythical Man-Month (4)
3    • Proposes a successfull rule of thumb:
4
5      –   1/3 planning
6
7
       –   1/6 coding
8      –   1/4 component test and early system test
9
10
       –   1/4 system test, all components in hand
11
12
     • Gutless estimating, or: an omelette example
13   • Regenerative schedule disaster:
14
15     – An example
16
17
       – Brook’s Law: Adding manpower to a late
18       software project makes it later.
19
20
1
2
           The Surgical Team (1)
3    • The problem: productivity varies hugely
4
5      between good programmers and poor ones.
6
7
     • Mill’s proposal: divide large job into
8      segments, each tackled by a surgical team:
9
10     – The surgeon. The chief programmer. Defines
11       spec, designs, codes, tests, documents. The boss.
12
13
       – The copilot. Less experienced, no responsibility
14       for code.
15
16
       – The administrator. Handles money, people,
17       space, machines. May be part-time (serve two
18       teams).
19
20     – The editor. Improves and perfects the
1
2
           The Surgical Team (2)
3        documentation produced by the surgeon.
4
5
     –   Two secretaries. One for the administrator and
6        one for the editor.
7
8
     –   The program clerk. Responsible for maintaining
9        all the technical records of the team in a
10       programming-product indexed library.
11
12   –   The toolsmith. The system manager of the team.
13
14
     –   The tester. Responsible for producing or
15       gathering the test-cases. ―The adversary‖.
16
     –   The language lawyer. Master of the used
17
18       programming language. Can serve two or three
19       teams [surgeons].
20
1
2
     The Surgical Team (3)
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
1    Aristocracy, Democracy and System Design
2
3    • Conceptual integrity is the most important
4      consideration in system design.
5
6
       – The ratio of function to conceptual complexity [user-
7
         side] is the ultimate test of system design. Measures
8
         ease of use, valid over both simple and difficult
9
         users.
10     – Simplicity is not enough. Straightforwardness is
11       required.
12     – To achieve it, a design must proceed from one mind
13       (or small group of agreeing minds).
14
   • Aristocracy vs. Democracy [Architecture vs.
15
16
     Implementation]:
17     – Blaauw: ―Where architecture tells what happens,
18       implementation tells how it is made to happen‖.
19     – This separation is very important
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
5
         • are welcomed, but magical enhacements cannot be
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            is
          ItPlan wrong because:
10
11       • Assumes ―one-shot‖, assumes realization
12         mistakes only
                 Code
13
14
         There must be upstream movement.
                        Component
                           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.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:19
posted:4/19/2010
language:English
pages:70