10 lessons from Mythical Man Month

How is it that a book written on software development 40 years ago still have immutable truths, even after such rapid technological progress? We were rereading Mythical Man Month as the first book in our newly formed Engineering Book Club and had good discussions every week for last few weeks, each time surprised how relevant the observations are still today. I wish more people in software engineering had read this book, it could have avoided lot of mistakes. Here are some of the observations which could serve as reminders about fundamentals.

1. Estimation of large system development is hard. We are still over optimistic with estimates done at early stages of requirements. Estimates are treated as sacrosanct, plans created on that considered absolute and fixing it on the run by adding more people is still tried and failed.

More software projects have gone awry for lack of calendar time than for all other causes combined. Why is this cause of disaster so common?

-?????????First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.

-?????????Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

-?????????Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef.

-?????????Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.

-?????????Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.

2. We don’t know what we want. But we still rationalize on why our idea is absolutely right and proceed to build it, only to get stuck with incoherent systems or abandoned features.

For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation.

Both the actual need and the user's perception of that need will change as programs are built, tested, and used.

Clients do not know what they want. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified. I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.

3. Nine women can’t deliver a child in a month. But still we try.

When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule.

Brooks's Law:

Adding manpower to a late software project makes it later.

4. System design cannot be done by a committee or broken into parts and done by many. It must flow from one mind or few like minds.

Conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.

5. Great engineering managers are rare. ???

The producer and the technical director may be the same man. This is readily workable on very small teams, perhaps three to six programmers. On larger projects it is very rarely workable, for two reasons. First, the man with strong management talent and strong technical talent is rarely found. Thinkers are rare; doers are rarer; and thinker-doers are rarest.

6. Maintenance is slow killing of software, especially the mindless one.

Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.

7. Knowing what to build will continue to be the biggest hurdle in software development. We focus a lot on Developer Productivity and Engineering metrics. But unused features and failed products are not the ones where we spend most effort in getting right. It simply is because what can be measured is what we can obsess about.

The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.

The hardest single part of building a software system is deciding precisely what to build. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

8. Still no Silver Bullet? Will the likes of Github Copilot, OpenAI Codex, No Code/Low code etc end up producing the silver bullet? I am skeptical. ???????????

Building software will always be hard. There is inherently no silver bullet.

Inherent properties of the irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility.

9. Agile could have been a silver bullet, but 20 years since the manifesto, verdict is still to be out, especially in large system development.

Using rapid prototyping as part of a planned iteration in establishing software requirements. Growing software organically, adding more and more function to systems as they are run, used, and tested.

10. People > Process any day. Good architects, designers, programmers and managers will have multiplier effect.

Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge.

Very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.

Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!