Wednesday, December 22, 2010

top-50-programming-quotes-of-all-time

http://www.junauza.com/2010/12/top-50-programming-quotes-of-all-time.html

Tuesday, December 7, 2010

Mythical Man Month

http://www.comp.mq.edu.au/units/comp340/public/mythical.pdf

http://www.cs.virginia.edu/~twh5b/quals/presentations/The%20Mythical%20Man-Month.pdf

http://www.infoq.com/articles/brooks-design-book-review

http://blog.assembla.com/assemblablog/tabid/12618/bid/6213/Time-to-Vanquish-the-Mythical-Man-Month.aspx

Harlan Mills Proposal

http://www.comp.mq.edu.au/units/comp340/public/mythical.pdf

Harlan Mills Proposal
  • Each segment of a large project be undertaken by a team
    • Team organised like a surgical team with specific roles
    • One “surgeon” doing the butchery; everyone else in support
    • Few minds involved in design
    • Highly segmented/independent tasks
    • Minimal communication during operations; only ever 1-1
The Roles
  • Surgeon
    • Chief programmer
    • Defines all functional and non-functional specifications
    • Designs, codes and tests program, writes doco
    • Very experienced, very talented person
    • Considerable applications and systems knowledge in relevant field
    • Uses computer system to implement and test the code directly
  • Copilot
    – Backup for the surgeon
    – Can do everything the surgeon does
    – But has less experience
    – Shares in design as a thinker, discussant and evaluator
    – Surgeon tries out ideas on her, but doesn’t have to accept advice
    – Copilot communicates with team; relays advice to surgeon
    – Knows all code intimately; researches alternative designs
    – Bus accident insurance
    – May write code but not responsible for it
  • Administrator
    – Surgeon is the boss…BUT must spend no time dealing with personnel, space, money, machines, bureaucracy
    – This is the role of the administrator
    – Liaises with stakeholders
    – May be full-time if significant legal, contractual, reporting requirements
    – One administrator may serve multiple teams
  • Editor
    – Responsible for writing doco
    – Generates external and internal descriptions
    – Takes draft provided by surgeon and refines, clarifies, amplifies
    – Criticises and reworks
    – Manages versioning
    – Inserts references and bibliographies
    – Responsible for production and publication
  • Two Secretaries
    – Surgeon and administrator both have a secretary
    – Deal with correspondence and non-product files
  • Program Clerk
    – Responsible for maintaining technical records of team in programming-product library
    – Trained as secretary
    – Logs all input/output for filing and indexing
    – Archiving and source management
    – Makes code available for the team to review
    – Configuration management?
  • Toolsmith
    – Available to build customised utilities on request of surgeon
    – Can be called on to write procedures, libraries, macros etc
    – Any special tools for this specific project (not COTS)
  • Tester
    – Devises test cases and data from functional specification
    – Tests releases in an adversarial fashion
    – Responsible for building test harnesses
    – Plans test sequences for unit and regression tests
  • Language Lawyer
    – Experts in syntax and semantics of languages used in the project
    – Knows neat and efficient ways of doing things
    – Encyclopaedic knowledge of APIs and libraries

  • One creative genius drives team production
    • But supporting roles are no less important
    • Surgeon focuses on designing and developing the system
    • Freed up from supporting but essential activities
    • Radically different from projects where each person does their own design development and testing
    • Role specialisation is critical to gaining the increases in productivity over the “average” programmer
    • Surgeon has unilateral control over decisions
      • Conforms to social psychology studies on team productivity showing authoritarian models are most productive if less satisfying than democratic or laissez-faire models
      • Model supported by Baker’s 1972 study
      • How would you structure a team based on agile/XP methodology?