[INGELRII]

I agree. Mythical Man Month is a book to read. It's clear, interesting, and has better writing than summaries.

Many classics like this are so good because the author is among the first to observe new phenomena. They can write down what they have learned without cultural narratives that distort reality.

The hardest lesson in the book is the chapter 11 "Plan to Throw One Away". I have never seen this not to be the case in large systems. You must design the system to be rewritten. Accepting this is still a taboo.

> In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.2 Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.

>The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering that throwaway to custom- ers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down.

>Hence plan to throw one away; you will, anyhow.

[dmurray]

> The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer.

It's not that clear! Perhaps you will only learn the lessons of why the throwaway version sucked by delivering it to customers. And it might buy you a lot of time, perhaps multiples of the initial time to get the pilot working.

Brooks has a point, but it may have been more true in the days of shrink-wrap software than SaaS and continuous updates.

I'd argue that it's more important to build an institution capable of retaining knowledge. The worst results are when the pilot system sucks and a whole new team is brought in to build the second version. They'll inevitably start building their pilot version, which sucks, and repeat until management gets sick of funding new teams for the same project (I feel this happens disproportionately in banking for some reason). Instead, you need to keep substantially the same team around to fix their mistakes in the second version.

[johnnyanmac]

>The hardest lesson in the book is the chapter 11 "Plan to Throw One Away"

On the contrary, aren't factors like Microservices and all the constant prototyping at large companies encompass this? I feel in some ways they may have embraced the principle too much, to the point where prod doesn't have a properly stable solution to support while they are re-writing an experimetal "improvement".

[zdragnar]

Part of the problem is you don't necessarily understand the problem domain very well when you're starting out. There are plenty of examples of microservice architecture failures due to incorrectly dividing services- either causing too much internal communication for performance acceptance criteria, or struggling with service coordination when performing changes that impact multiple relationships.

You may well end up throwing away some or many of your early microservices as you grow and the company better understands what it wants to build.

Or, you can take another approach (which i have witnessed first hand), throw it all away and go back to a regular, well designed monolith and getting very significant performance improvements by doing things like SQL joins and transactions instead of putting events in a message queue and paying network traffic penalties.

[mushufasa]

Well, this was a bigger issue when this book was written and software was typically developed on disks that couldn't be updated after sale. In the SaaS world, I think deploying your MVP and then rewriting/improving while you have customers running into real world feedback and pain points, and also generating revenue to validate market demand, is strictly preferable to taking an extra cycle and not be in market.

[namaria]

I understand the drive to consume book summaries instead of books themselves. There are way too many books, life moves fast, we need results yesterday.

I also think that if we summarized all the great books ever written and boiled them down to one phrase, it would be "read more books".

[kwertyoowiyop]

Such great writing. Clear, compelling, and entertaining.