The Mythical Man Month · Fred Brooks · 1975
As books are abundant but time is scarce, I think carefully about what to read. It's easy to succumb to hype and develop a powerful recency bias in book selection. Knowing that only a handful of this year's books will become classics, I'm trying to get through the important texts of the past too.
The Mythical Man Month is a collection of learnings about how to build software, it’s often referenced but seldom read by technology professionals. A lot has changed since 1975, so plenty of this book can be discarded. BUT it’s still worth reading as what’s still true today, will likely be true forever.
Key Highlights
- Many large software projects fail, some emerge with running systems, few meet goals, schedules and budgets.
- No one thing seems to cause the difficulty, but the probability of a large programming project going well with lots of tasks dependent on each other is very small.
- Most software projects go awry due to lack of calendar time (vs all other causes combined).
- We are bad at estimating. Most programmers are optimists (probably because learning to program is so frustrating only the optimists remain).
- Our estimating techniques confuse effort with progress, hiding the assumption that men and months are interchangeable.
- When we detect a delay, we add more people (which can make things worse not better).
- The person-month as a unit for measuring the size of a job is dangerous and deceptive. It implies that men and months are interchangeable. This would only be true if tasks can be perfectly divided and there be no communication overhead. This is true of reaping wheat but not systems programming.
- When a task can't be partitioned, more people don't help (it takes 9 months to make a baby).
- When a task can be partitioned, but with communication overhead, you need to add the overhead to the work. Theres both a training and intercommunication overhead. Intercommunication is tricky. The number of nodes increases exponentially (the power of network graphs in reverse). Dumbar's number style effect. Since software construction is inherently a systems effort, an exercise in complex interrelationships communication effort is great, and dominates the effect of adding more people to the project.
- We expect there to be no bugs. Failure to allow enough time for testing is disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until the delivery date. Cost per day is also normally at its highest at this point.
- The Team Size Dilemma: For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems, one wants a way to bring considerable man power to bear, which requires considerable communication cost.
- Each segment of a large job can be tackled by a small surgical team. Instead of everyone cutting away at the problem, one does the cutting. Everyone else gives him the support needed. Few minds involved in design and construction, many minds brought to bare.
- To build things that take 5k person years you need multiple surgeons who have to spend all of their time talking to each other about the system architecture.
- Conceptual integrity is the most important consideration in system design, it dictates that the design must proceed from a very small number of agreeing resonant minds. So we need either: careful division of labor between architecture and implementation, or a new way of structuring programming implementation teams.
- Implementers raise objections to architects doing the design. Their jobs are less interesting, the designs are likely to be less practical, there will be a delay while specifications are created.
- Written Specifications are necessary tool - although not sufficient. The manual must describe what the user sees, and refrain from talking about what they don't see. That is the implementers business. His design freedom must be unconstrained.
- The purpose of the organisation is to reduce the amount of communication & coordination necessary. Division of labour and specialisation of function. The communication structure should be a network not a tree.
- Thinkers are rare, doers are rarer and thinker-doers are rarest.
- The bigger the product the harder it is to build and test. You can't extrapolate 100m sprints to a 3 minute mile. Typically programs of half the size take a quarter of the time. Effort goes up as a power of size even when no communication is involved except that of a man with his memories.
- Programming teams take 2x as long as they think. The miss was because the teams spent only 50% of the working week programming. We overestimate the amount of time we get to spend on programming.
- Write decisions down, it will help you spot gaps in your own logic, communicate with others and create checklists for implementation.
- With most complex systems, the first system built is rarely usable. You'll have to make some major changes and rebuild. Always play to build a throwaway.
- Accept change as a way of life. But the threshold for changes must be raised overtime, otherwise no product ever emerges.
- The more users you have, the more bugs they’ll find. Every time that you fix a bug, theres a 20-50% chance you introduce one.
- Systems program building is an entropy-decreasing process, hence inherently metastable. Maintenance is entropy-increasing process = which leads to unfixable obsolescence.
- The crucial task is to get the product defined. Many failures come from areas of the product that were not quite defined.
Full Book Summary · Purchase on Amazon · More Book Summaries
Subscribe and share Product so you and your team can keep pace
with Product Management and related fields.
< Subscribe Now Button >Quick Links
- Turns out the placebo effect isn’t a thing · Paper
- Lessons from running a tech meetup · Article
- Doshi on High Agency · Tweet Storm
- How adding salt helps store passwords securely · Tweet
- DeepMind reinforcement learning lecture series · Videos
- Blending is all you need (LLMs) · Paper
- Designing for the scent of information (UX/Navigation) · Paper
- Concise, SCANNABLE, and Objective: How to Write for the Web · Article
- An Introduction to Experiment Pairing · Article
Destructive Creation, Creative Destruction, and the Paradox of Innovation Science · 2022
- The paradox of innovation: when stable patterns of innovation are understood, codified, and institutionalised, it stops being true innovation. This goes beyond semantics. Once innovation becomes predictable and integrated into established economic and societal systems, it loses its ability to bring about new and unexpected changes.
- Both Karl Marx and Joseph Schumpeter recognised modern capitalism as an engine of innovation, but they doubted its predictability and sustainability.
- Innovations tend to emerge when established structures and their defences are dismantled, leading to conflict and chaos. The author’s coin the term destructive creation to describe this process which precedes the companion process of creative destruction. In creative destruction, emerging innovations make previous ones irrelevant as they are spread and supported by social, cultural, and technical structures.
- What’s important to innovation?
- Cognitive Conflict: Encourages the challenging of existing ideas and assumptions, leading to new perspectives and creative solutions.
- Diversity: Brings varied experiences, viewpoints, and skills, which contribute to a richer pool of ideas and approaches.
- Team Dynamics: Effective collaboration and interaction within diverse teams enhance the ability to address complex problems innovative ways.
- Network Centrality improves innovation performance. This is attributed to more control over information and resources and greater access to dissonant information across otherwise disconnected individuals and organisations.
- Innovative success enriches and empowers once-innovative individuals and institutions, which then may defend against new waves of innovation. This resistance to change forces novel sources of innovation to emerge from new areas of science, technology, and society.
- Technological advances in capitalist societies can increase relative surplus-value, narrowing the accumulation of capital to the winners of industrial competition. This enlarges the wealth gap and potentially incentivises the destruction of capitalism from within.
Book Highlights
Not all customers are created equal. You want to learn from your best, your “pry it from my hands” customers who: understand the problem your product solves and have personally struggled with it; pay for the value your product provides without hesitation; have an ongoing need for your product; have reached what we call “value realisation”—they’ve clearly solved the problem they wanted to solve using your product; and began paying recently enough that they remember what life was like before they found your product. These are the customers you want to learn from, since these are the customers you want more of.Georgiana Laudi and Claire Suellentrop · Forget the Funnel
Ask why at every step—why is it like this now? How can it be better? Think like a user who has never tried this product before; dig into their mindset, their pain and challenges, their hopes and desires. Break it down into steps and set all the constraints up frontTony Fadell · Build
A good persuasive technology largely depends on taking what was formerly invisible (behaviours, decisions, unseen consequences) and making it visibleAmber Case · Calm Technology
X-Rated (Best of Product Twitter)
Many people won't attempt something unless they can find an example of someone else who is already doing it. Rely on this type of thinking too much and you'll never do anything interesting.
James Clear · X JamesClear
Still blows my mind that you take ANY MIT course you want, online, for free. Machine learning? Nuclear physics? Quantum computing? All there. Truly unreal.
Christian Keil · X Pronounced_Kyle