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.
It'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.
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.
> 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?
Second-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.
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.