3 ms·
Fred Brooks as usual stands the test of time. It's incredible how many times I've quoted some part of Mythical Man-Month in my career, it's also part of the rec
by piva00 2y ago
Fred Brooks as usual stands the test of time. It's incredible how many times I've quoted some part of Mythical Man-Month in my career, it's also part of the recommended literature I give to every junior I've trained in my life.
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.
- eru 2y agoIt's always amusing to read Fred Brooks' own lamentations. 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.
- bckr 2y agoSurely we’ve learned some things? 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?
- skydhash 2y agoPeopleware by Tom Dermaco & Timothy Lister. Making Things Happen by Scott Berkun. Bu I haven’t finished reading it yet.
- eru 2y ago> Surely we’ve learned some things? 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.
- scubbo 2y ago> Hence plan to throw one away; you will, anyhow. > 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? [0] https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
- nabla9 2y agoPrototype is not the first system.
- mpweiher 2y ago"If you plan to throw away one, you will throw away two" -- Programming Pearls https://tildesites.bowdoin.edu/~ltoma/teaching/cs340/spring05/coursestuff/Bentley_BumperSticker.pdf https://tildesites.bowdoin.edu/~ltoma/teaching/cs340/spring0...
- piva00 2y agoSecond-system effect is the replacement of a full production application with another full blown production application where the second-system has to replicate all (or at least most) of the features from the first-system into the second one while also adding new features into the second-system. Even worse are the cases where the first-system still has to coexist and keep being developed while the replacement second-system is in development, that usually leads to a never-ending catch up of the second-system trying to integrate all the changes from the first-system that happened after the start of the second-system project. Have you read the book? I'd recommend it!