I’ve been aware of the book titled The Mythical Man Month for quite some time now. It’s meant to be a must read for any software project manager. It’s about time I go through it, I was running the risk of being shot!
Any software manager who hasn’t read this book should be taken out and shot.
It’s definitely a good read, I learned a lot from it, below are some comments on the things that made me react.
Old but still kicking!
This book is relatively old, it was originally published in 1975 and the most recent 20th anniversary edition I purchased is already more than 10 years old. So you could ask yourself does it really matter today? With all the changes in the field during the last 30 years, should I really care? It’s almost like archeology at this point, isn’t it?
Some parts of the book are dealing with actual implementation, they’re not so many of them and they often contain some general wisdom. I confess, I skipped a couple pages where I was getting drown into implementation details (company name, system version, languages) of little use to me but that’s a really small percentage of the content.
Truth is, this book is not so much about technology than it is about groups of people achieving complex tasks so it’s still relevant nowadays because people haven’t evolved much in 30 years.
Some fuel for day to day arguing
I was happy to find in this book multiple references to studies, books and articles providing me with facts to help me convince people around me of the good/toxicity of certain practices. Some examples of this:
- Hoping that everything will go well is foolish
- Man and Month are not interchangeable. Add too many people at the wrong time and you’ll be later, your time will be spent in training and inter communication instead of actual development.
- Adding more people = more work for everybody
- Architect to embrace change
- Two step forward and one step back: fixing a bug has a 20-50% chance of introducing new bugs
Many of these points are obvious when you think about it but I often struggle to clearly demonstrate it. Moreover, as the proverb says: “No one is a prophet in his own country” , so when you’re trying to convince management, or anyone, of something, it helps if you can say: “Look! This ultra famous guy says the same thing in his book”.
Interlude: Size matters!
It’s a bit of a side note, but the “size matters“ argument, or more exactly “program space as cost”, appears in the book in the context of system programming back in the 60’s when memory was not so abundant. So you could say that now that we got crazy fast computers with myriads of CPUs and tons of RAM it’s an outdated concern. But a speech by SUN’s CTO and a few articles such as this one woke me up to the idea that size is coming back in the equation. For example, it has an obvious economic impact in the relatively new world of cloud computing such as Amazon EC2 and S3 services for which you get billed by machine configuration, CPU and bandwidth usage. Even for company running their own farms of machines, there is a cost associated with the data center.
30 years old somewhat Agile methodology
Continuous integration, incremental, iterative, etc. I was expecting a lot of Waterfall and related project management concepts but I was surprised to discover that a lot of the ideas in the book are very “Agile”. A reminder to myself that the concepts are not new. Those who know everything will excuse my surprise as I walked through this book reading description after description of agile practices. But after all, Agile methodology is mostly common sens.
Statements such as “the Only Constancy is change itself” or “Architect to embrace change” are typical in the book.
I read:
“It is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirement of a modern software product before having built and tried some versions of the product they are specifying.”
That was in 1975… So I ask the question, why are we still trying to get the perfect spec? Why is it that I’m asked to produce documents where I’m pretty much guessing the future?
It seems that our industry as a memory problem. Is it a symptom of the lack of maturity of the field?
Tons of example like this: Rapid prototyping, Growing software organically, Finding unobtrusive control methods, using clean debugged component saves a lot of time during component testing (test early).
The author is all about communication.
I like Agile principles because it takes into account the actors of the game (us). We’re not flawless so the methodologies should be oriented toward protecting us from ourselves and not adding more activities that we will potentially screw up. It’s the whole idea that writing down an idea helps dispel the inconsistencies. It’s a form of trial by fire and reminding me of the saying “What is clearly understood can be clearly explained”.
But still there is a smell of waterfall
He’s talking about testing the specification before using it for implementation. It’s agile in the sense that it’s an attempt at shortening the feedback loop but still his aiming at grasping the whole thing before getting down to the dirty work. Smells like waterfall…
He puts a big emphasis on documentation (Objectives, Specs, Schedule, Resources). For the record, I’ll join him on the importance of a diagram. To reuse his terminology, I see UML as a powerful tool to fight the “invisible aspect of software”. But I would avoid aiming at the Pulitzer with my documentation. Truth is that in the world (mine at least) most people don’t read it. In my current environment, at best, it’s a ‘cache’ I use to shorten my interactions with people asking questions. But they still come to me first.
Conceptual integrity is the key
Amidst this agility, the author still retain a somewhat rigid approach illustrated amongst other thing by his attempt to control everything in one place. For him, a centralized decision power is a key, the system needs to be born out of a single (+ backup) mind in order to be consistent and survive. I’m not too sure I agree with that for couple reasons: I think creating artificial communication barriers, for example by separating people in categories: developer, architect and forcing formal communication between them, will only hinders work. Also, people make mistakes so I believe it’s better if nobody (but the majority) has the hierarchical upper-hand in an intellectual discussion, and sometimes the best ideas comes from where no-one expected.
In the end I think I’m more of a believer in the natural way, the best idea should prevail even if it’s coming from a junior developer. Also I believe people work better if they’re implicated in setting the global direction, because you give more value to something you’ve contributed to build. Also people sharing the vision and participating in the thinking process will be on the same “wave length” which will reduce the amount of necessary communication in their day to day interactions.
Spending your time with machines makes you weird
The book doesn’t mention the whole discipline of Usability engineering. His approach seems to try to guess the user rather than directly study the user. His argument seems to be the cost associated with it. But As far as I’ve observed, there’s a strong disconnect between software engineers and regular (non tech savvy) end users. Plus generally software engineers are not the most empathic beings and they lack a lot of education necessary to interpret the user ’s expression of his need.
(to be continued in part 2…)
