The Mythical Man Month
Timeless Advice
Experience is a dear teacher, But fools will learn from no other.
This book marks the first time that I’ve properly done 2 things:
First thoughts are that this book is referencing projects that I haven’t heard of from a time when software engineering looked completely different to what I know right now. There is barely any mention of technologies that I am familiar with. Only at the very end in added chapters do we get a reference to C++.
The way that the book is written is quite appealing. The prose is very well structured. Very few extraneous words are said besides the arguments that is currently being made. Each argument is also very logically thought out. To the point that the book gives a summary of all its key points in one of its later chapters.
There are some very simple yet enlightening ideas that are proposed. With my own naive tracking of software development practices throughout the years I can see myself what might have been, compared to what is today.
Some of the key arguments that i took away are regarding ‘small lean teams’ and ‘constant documentation’. The lean team advice is already quite popular throughout the SWE landscape. You hear a lot of talks about AGILE teams and the such. They are however not implemented in the exact way that the book outlines. To me, most agile teams are built from groups of equals. With a loose hierarchy depending on the subset of project that each person mans. Fredrick instead argues for a single person to do the bulk of the design work. With everyone else being there to implement this design. (With freedom for how they approach the interfaces/functionality that they are supposed to make.)
The second point is regarding constant documentation of changes in the project, its scope, constraints, and most importantly decisions/architecture. I like this idea. I’ve been spending some time recently going through the public Oxide RFD’s. Seeing a company document ideas that are normally implied, or taken for granted, is something that I’ve never thought of doing. I must confess that long form reading is a rare thing to do in today’s world. So perhaps this kind of documentation is a fools endeavour. The sentiment is one that I applaud, and would love to try to implement in my future managerial roles.
An Artists Job
Frederick quite beautifully states that programming is an endeavour that “gratifies creative longings deep within us and delights sensibilities that we have in common with all men”. The most poetic description of the craft that I’ve seen put on paper. A description that heightens it above mere nerd work behind a screen. The extensions of this analogy carry quite cleanly as well. As one would imagine artists to have skill sets that are in no linear progression, so does one see the same in programmers. Frederick argues that the best of us are at least 10x better than the average. That this jump in quality is also not proportional to time spent on the craft either. Your ability to build beautiful castles in the sky comes not from building a lot of them.
Fear of Commitment
Reluctance to document architecture comes not from laziness, rather from hesitancy to defend decisions that are tentative.
This one struck close to home. I’ve always preached about documentation more than I’ve practiced. I expect better documentation from others than I hold myself to. And whilst I had never considered why I have found documentation such a tedious task. This quote adds colour to hindsight.
I think there are few tasks and decisions that I make where I am so sure of the reasoning behind my choices that writing documentation for them would be trivial. Something that I’ve truly looked at so thoroughly that I can analytically disarm all alternatives and defend my choice. I suppose that this is a goal I would like to aim towards. A lofty ambition that I might one day be able to achieve.
There are a lot of other gems in this book. Some of them geared more towards the human aspect of managing teams. For instance, the idea that day-to-day slippage is the leading cause mortality of all projects. That inadequate time is the single biggest factor behind incomplete projects. That companies can only ever build things that communicate in the way that they communicate. Gems that I shall be revisiting in the future. I see why this book stands as a landmark in the space of managing people.