The Mythical Man Month: Essays on Software Engineering - qu-reeds/qu-reeds.github.io GitHub Wiki

[via a review on GoodReads]

  • Estimating software project completion time is really hard. (Requirements change, software is intangible and it has to fit with idiosyncrasies of human systems)

  • Aristocracy in managing projects is better. There should be one final decision maker. Metaphor is a surgical team.

  • Cost of coordination and communication within large teams is often ignored. This causes poor estimation.

  • If a project is delayed - rescheduling or reducing scope is recommended. Adding manpower will result in further delay.

  • Avoid cramming features in the second system (reminded me of Vista)

  • Written specification is very important. It should describe everything that the user can see about the product.

  • Algorithm can be predicted from the data tables.

  • Small number of documents become the pivots of product management (Objectives, Specifications, Schedule, Budget)

  • Quantify change by using version numbers

  • More bugs are found as the number of users increases

  • Things are always their best at the beginning

  • Repairs (software) increase entropy

  • "Sustained concentration reduces thinking time"

  • Milestone should be concrete, specific measurable events. Pay strict attention to even the slightest delays, Projects get delayed one day at a time.

  • Hard part of building software is: specification, design, & testing

  • Creative activity has three steps:

  1. Formulation of conceptual construct
  2. Implementation in real media
  3. Interativity with users in real uses

  • "Conceptual integrity of the prodcut as percerived by user is the most important factor in ease of use"

  • Use keyboard shortcuts to design for power users and novices

  • "People with more time take more time"