📖The mythical man-month: essays on software engineering

authors

Brooks, Frederick

year

1995

• p.5

  program (1x)	programming system (3x)
  programming product (3x)	programming systems product (9x)

  • program is what usually created in garage (raw functionality)

  • system: larger

  • product: docs, tests, etc.

  • Xs show how much effort is needed to create

  • how does this play with agile?

• Surgical team ↔ cross-functional?

• Conceptual integrity p.43

  • Architecture is equated to product design/specification. The main goal is to make it easy for users. The book talks about OS and PLs though.

  • This use of architecture aligns with architecture in CPUs—instruction set.

  • The second-system effect might thus be more about requirements than architecture.

• § Plan to throw one away

  • the first version is always pilot

    • (how true is this? especially now with agile)

  • you don’t have a choice whether you will throw it away or now—the question is whether you ship the pilot to the customers

  • p.118 → By documenting a design, the designer exposes himself to the criticism

    By documenting a design, the designer exposes himself to the criticism of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible. —John Cosgrove, “Needed: A New Planning Framework,” Datamation 17-23

  • plan the organization for change

    • programming and managerial roles should be of the same level/prestige

    • tech leads should be able to manage, and managers should be ready to code

      • (the books seems to show the age—I believe there were no non-technical managers on software projects back then)

  • in 20y perspective, seems to be wrong p.265

    • incremental build model is better

• p.144

  Further, some have become very doctrinaire about avoiding all GO TO’s, and that seems excessive.

• p. 153

    How does a project get to be a year late?
    … One day at a time.
  

• PERT charts

• Reducing the role conflict. (p.157)

  • Distinguish between action information and status information. Do not act on problems your (subordinate) manager can solve, never act on problems when you review state.

  • Disambiguate status/action meetings clearly

• documentation

  • provide overview (to use program)

    1. purpose

    2. environment

    3. domain and range

    4. functions and algorithms used

    5. input-output format

    6. operating instructions

    7. options

    8. running time

    9. accuracy and checking

• § There is no silver bullet → Essential vs. accidental in software development

  • it’s not software that is slow, it’s hardware that is fast. No other technology has improved 6 orders of magnitude in 30 years (p.182)

  • p.182

    I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

  • p.199

    No other part of the conceptual work is so difficult as establishing the detailed technical requirements.

    • (that’s what architect’s responsibility is?)

• Herzberg, Mausher, Sayderman. Motivational factors can increase productivity (p.210)

  • removing awkwardness, long turnarounds, poor tools can help

• Requirement of precision

  • (how to make programming require less precision?)

• Essential vs accidental

• “Focus on quality and productivity will follow.” (but productivity drops again as one pursues extreme qualitiy) Capers Jones (p.217)

• One issue with OO is that they experimented targeting low, not high. Instead of user interfaces and complex things, they build lists and sets. (p.220)

• OO focused on languages more, but should have been focusing on design (teaching users to design better) (p.221)

• Brook’s law: adding manpower to a late software project makes it later (p.232)

• p.233 → Architect as guard of conceptual integrity

  If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology.

• p.233 → Architect only suggests

  The builder has the creative responsibility for implementation; the architect only suggests.

  • p.233

    [As an architect,] be ready to forgo credit for suggested improvements.

• Managing software project is closer to any other management then any programmer would initially think. (p.255)

• Architect is user’s agent. He works in the interest of the user (p.256)

• p.256

  The architect is like the director and the manager like the producer of a motion picture.

• Conceptual integrity is central to product quality.

• p.259

  Write down explicit guesses for the attributes of the user set. It is far better to be explicit and wrong than to be vague.

• Small is Beautiful: Economics as if People Mattered by Schumacher #book

• Fourth-generation languages (p.283)

• reusable off the shelf component attack the essence of software development (p.285) → Reusable off-the-shelf software components attack the essence of software development

Backlinks

• 📖 Cooperative Software Development
• 📝 Architect as guard of conceptual integrity
• 📝 Architect only suggests
• 📝 Reusable off-the-shelf software components attack the essence of software development
• 📝 Brooks’s law
• 📝 Essential vs. accidental in software development
• 📝 By documenting a design, the designer exposes himself to the criticism
• 📝 Architecture as product design/specification