Failed and not fun games do happen, but in general game developers put far more weight to this sort of process. There are no other goals that you can claim were accomplished if the users think the game sucks. So you get these ruthless production cycles and there's an appetite to cut things that don't work.
I've noticed lately that it's become less common someone in the room has read it when I mention a passage from it, be it management or other software devs. Not sure why but it used to be much more common that I'd bring the argument against a Second-System and at least one other person would recognise it, or the issues with communication channels between a larger group.
For any professional software developer out there who haven't read it, please do, it's a collection of wisdom from 50 years ago that still applies today.
> Fred Brooks as usual stands the test of time.[...]I'd bring the argument against a Second-System
I'm confused. The GP appears to be saying that one should plan to build two systems - one as a proof-of-concept, and another (which is actually presented to most customers) in which one does things "the right way" based on learnings during that process - whereas you (and Fred[0]) seem to allude that the second system tends to be bloated and over-engineered. What am I missing?
Have you read the book? I'd recommend it!
https://tildesites.bowdoin.edu/~ltoma/teaching/cs340/spring0...
He's flattered that people still quote him, but also horrified that what he thought was his first, fledgling start in software project management is still quoted as start of the art. We haven't learned anything.
After Mythical Man Month there’s been other books (and talks), yes?
I’ve read The Phoenix Project (based on The Goal) and its sequels.
What should be on every EM’s shelf?
I was exaggerating a bit.
Brooks lamented that we've learned so little, that his observations stay relevant, instead of being superseded by something more systematic.
In contrast, if you were learning how to write a compiler or operating system today, you (hopefully!) wouldn't pick up a book published when the Mythical Man Month came out.
Making Things Happen by Scott Berkun. Bu I haven’t finished reading it yet.
Both situations require design around uncertainty, but the chemical engineer is looking for practical kinks in a roughly-understood system. The programmatic system has no idea what is value add, what will stay or go or anything like that. In the extreme case you get things like Slack or Discord, where the plan wasn't even trying to build communications software to start with.
The nature and scale of the uncertainty is different. Software needs to adopt a fail-fast iterative approach with lots of feedback. Chemical engineers are looking for something else. The "pilot plant" concept wouldn't carry to software. Although the "we're going to throw this out" attitude works wonders (unless you rely on it happening, in which case that code is permanent now for some reason).
Pilot Plants and Scaling Up Chemical engineers learned long ago that a process that works in the laboratory cannot be implemented in a factory in only one step. An intermediate step called the pilot plant is necessary to give experience in scaling quantities up and in operating in nonprotective environments. For example, a laboratory process for desalting water will be tested in a pilot plant of 10,000 gallon/day capacity before being used for a 2,000,000 gallon/day community water system.
Programming system builders have also been exposed to this lesson, but it seems to have not yet been learned. Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built.
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.[ 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 customers 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.
You know the source.