This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.
Experience tells Frederick P. Brooks that the first system built is always barely usable. So many years after the book was published, that is also my experience: I never worked in a company that didn’t have at least one previous version of their software that was completely thrown away!
So It seems we never get it right the first time. Maybe because we don’t have enough technical knowledge, maybe because we don’t have enough knowledge of the domain, maybe because we are in a startup and need to do it quick and dirty.
Maybe doesn’t even matter.
What does matter, is that it happens.
The management question here, 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 and throw away, 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.
Edit: In the Epilog of the 20 years anniversary edition, Brooks mentions that he does not totally agree with this anymore. His view was very tied to Waterfall and nowadays throwing one away can be avoided by using what we nowadays call Agile.
The only real constant is change itself
As we build a project, time goes by, the context where the project exists changes, the functional constraints change, the users needs change, the hardware used changes.
Change is inevitable.
We need to realise, understand and accept this if we are to be able to plan for it.
Prepare the system for change
Since change is a given, we need to prepare the system for change.
The usual way to do this is through modularity and encapsulation, allowing us to change or replace part of the system without impacting the rest of the system.
Nevertheless, there are other techniques we can add to the previous one:
- Self-documentation
- Compile time operations
- Executable documentation
- Testing
- (Semantic) Versioning
Prepare the organization for change
The whole workforce must be flexible, and that means that individuals must have broad capabilities and expertizes.
On a large project the manager needs to keep two or three top programmers as a technical cavalry that can gallop to the rescue wherever the battle is thickest.
People must be as interchangeable as their talents allow.
The career structure, the hierarchy, also needs to change as the organization changes. It seems that a minimal amount of career levels favours flexibility.
It is easy to align salaries along different career paths levels, but the prestige, the social status that they give is much more difficult to juggle with. Not only salary but also office space and support services must be equivalent in the different career paths.
Methods of redesigning software that prevents bugs have an immense payoff, and so do methods of implementing a design with fewer people, as there will be less communication needed, therefore less chance of misunderstandings, easier alignment and coordination and less chance of bugs.
@hgraca 