I purchased this book as a parting gift for the project manager of my first co-op term. Unsurprisingly, having never managed a software project before, I did not find this book as profound as a PM probably would. Furthermore, some topics discussed are completely outdated now, like how to efficiently allocate usage of the mainframe so everyone gets a chance to debug (imagine not being able to just ask ChatGPT). So because of my youth and inexperience, this book gets a lower rating than it probably deserves. Here are some interesting takeaways.
Key Insights
- Unlike strawberry picking, adding more people to a programming team will not always get the job done faster. Reasons include the cost of training, time spent communicating, and the existence of unparitionable sequenced tasks like debugging that do not get faster with more people.
- Conceptual integrity should be elitist. A small group of architects can develop a more effective design to be implemented by a larger group of implementors. The two groups must communicate, but never overreach their responsibilities.
- Second-System Effect: The second iteration of a product tends to be overambitious.
- In the life cycle of a product, many bugs are found at the beginning. As these are fixed and new features are added, users reach a "new plateau of sophistication" and more subtle bugs reveal themselves. Thus the graph of bugs against time tends to be U-shaped.
- Program maintenance increases 'program entropy'. In later fixes, programmers spend more time fixing flaws introduced by earlier fixes. Eventually, a rewrite is required.
IRL Update: I read this book in August 2023 but never got the chance to write something before school started. Then I put it off and forgot about it. Better late than never though right?