The Mythical Man-Month - software is grown, not constructed

An older colleague with a lot of experience recommended this to me as a classic, and I can see why it has stayed popular for decades. It gets 4/5 from me.

On the surface it’s about project management for software, but the ideas apply to all kinds of projects. The core argument goes like this. The best case scenario for a project is two or three minds focused on getting it done, with one person holding a strong vision and the final say. As you add more minds, efficiency drops because the communication and management overhead grows rapidly. I’ve seen this play out in real work: some clients assume adding more devs will double or triple the speed, but that never happens. Yet many projects need to be solved quickly so they’re not obsolete by the time they ship, think a modern operating system or a large mobile app. The only way to go faster is more minds, splitting the problem up and solving it in parallel. The book explores that tension and what the author has seen actually work.

Another highlight is the “no silver bullets” discussion: there’s no order of magnitude improvement coming to software development in the next decade, so focus on incremental improvements to your process instead.

My favourite concept is that software should be thought of as “grown” rather than “constructed”. It fits agile perfectly, and I’ve since put it into practice. On McFly, a project we’re building in house, I structured everything as modular as possible so it could grow in any direction. Modules for SendGrid, Stripe, Slack and task runners all grew out of the codebase naturally, and we didn’t even know we’d need most of them up front.

My one complaint is the 20th anniversary edition I read. Some chapters are simply obsolete, and even the author admits in the summary that the ones on program storage space and the “daily change log printout” aren’t relevant today. Those should have been cut.

Still a great read for both engineers and managers building software in a team.