I am reading currently The Mythical Man-Month because I feel like it's such a valuable resource to summarize my general project management knwoledge in a readable format.
I found this link, which summarizes the whole book pretty well, I wanted to save it for my personal collection, so I'll just copy it over to find it in the future (been searching for it lot of times, got tired of it haha).
Tar Pit (What is programming)
Software like a tar pit: The more you fight it, the deeper you sink!
No one single thing seems that difficult; "any particular paw can be pulled away." Simultaneous and interacting factors brings productivity to a halt.
A program is just a set of instructions that seems to do what you want. All programmers say "Oh, I can easily beat the 10 lines / day cited by industrial programmers." They are talking about just coding something, not building a product.
A product (more useful than a program):
- can be run, tested, repaired by anyone
- usable in many environments on many sets of data.
- must be tested
- documentation
Brooks estimates a 3x cost increase for this.
To be a component in a programming system (collection of interacting programs like an OS):
- input and output must conform in syntax, semantics to defined interfaces
- must operate within resource budget
- must be tested with other components to check integration (very expensive since interactions grows exponentially in n).
Brooks estimates that this too costs 3x.
A combined programming system product is 9x more costly than a program.
Why is programming fun?
- Joy of creation
- Fun making things people use
- fascination with complex puzzles
- curiosity, learning
- working in an etherial medium like a poet
On the other hand...
- you have to be very precise
- you rarely control what you are to build (specs)
- dependency on other programs, programmers
- finding bugs is a drag and very difficult
- takes forever to build anything big
- product obsolete when you finish; people are after next big thing before you finish (can make the current project wander and never finish)
Mythical Man Month
Why does software fail?
- Difficult to estimate time
- Optimism
- Effort != progress
- Schedule not monitored
- Slippage induces addition of people
Brooks says programmers are optimists (everything will go right etc...). Incompleteness and inconsistencies become clear only during implementation. He concludes that experimenting, "working out" are essential disciplines.
Each task has a nonzero probability of failure or slippage. Probability that all will go well is near zero.
Cost varies with manpower and resources, but progress does not! Hence, using "man month" (person month) as a measure is misleading and dangerous. They are interchangeable only when there is no interaction whatsoever between tasks.
- Draw line downwards top left to lower right months (y) vs people (x) for a perfectly partionable task.
- For semi-partionable task, show convex downward curve top left to bottom right
- For unpartionable task, show flat line from same months vs people graph.
For partionable tasks that require communication, must add communication to the cost of completion. Communication is:
- training (technology, goals, overall strategy, plan of work)
- intercommunication; if each pair must communicate, cost grows with "n(n-1)/2". Meetings of >2 people makes it even worse!
For building a system (requires lots of communication), the communication effort quickly dominates the effort. Adding more people lengthens not shortens the schedule
Testing cost underestimated always. Brooks suggests:
- 1/3 planning (yes this costs a lot)
- 1/6 coding
- 1/4 component test, early system test
- 1/4 system test, all components in hand
TJP: don't forget that writing test harnesses can be almost as much work or sometimes more as writing the actual code.
Delays during final testing are very demoralizing!
Gutless estimating
Urgency of boss forces programmers to agree to unrealistic schedules.
It is very hard to defend an estimate (good or bad); people use "hunches"
Surgical Team
The difference between a good programmer and bad programmer is at least:
- 10x in productivity
- 5x in program speed, space measurement
The 20k/yr programmer is more than 10x more productive than 10/yr programmer (1960's salaries...i hope) ;)
Data showed no correlation between experience and performance (but clearly there must be some).
"Small" team shouldn't exceed 10 programmers.
Managers want small sharp team, but you can't build a very large system this way.
OS360 took about 5000 man years to complete. A team of 200 programmers would take 25 years (assuming simple linear partitionable tasks) Took only 4 years with 1000 people (quoting from book these numbers but don't seem to add up).
Instead of hiring 200 programmers what about this: hire 10 superstars with say 7x productivity factor and 7x reduction in communication costs. 5000 hours / (10 x 7 x 7) = 10 years. Hmm...may not work even still.
Harlan Mills suggests surgical teams: team leader (chief programmer==surgeon) with supporting surgeons, nurses. Chief does the cutting and other support.
Might be tough to find right mix of people, desires, skills (i.e., who wants to do the testing?)
- Surgeon: chief programmer
- Co-pilot: able to do what surgeon does but is less experienced
- Administrator: handles money, people, space, machines, etc...)
- Editor: surgeon must do doc, but editor must clean it up
- Two secretaris
- Program clerk: maintaining technical records
- Toolsmith: serves surgeon's need for tools, utilities
- Tester: Devise system component tests, does debugging
What's the difference? Surgical team: project is surgeon's brainchild and they are in charge of conceptual integrity etc... In collaborative team, everyone is equal and things are "designed by committee". Causes chaos.
How to scale? Large system broken into subsystems assigned to surgical teams. Some coordination between surgical team leaders.
Aristocracy, Democracy, and System Design
Conceptual Integrity:
- better to have one good idea than many bad or uncoordinated nonstandard ideas
- very important aspect of a large system.
- user has to know just that main concept; whole project makes sense. For example, in UNIX everything is a stream (files, devices, tty, ...)
- preserved by architect that designs system top-down.
TJP: in my experience, having a single mind behind ANTLR has made all tools, concepts hold together well. Most projects are "touched" by many grad students as they drift through a department and work on the tool for a prof.
Ratio of functionality / conceptual complexity is important.
One or a few minds design, many implement (per surgical team).
Brooks argues for separating implementation by using clock (hands, etc...) design with the many implementations. Architecture is what happens, and implementation is how it happens.
Defending aristocracy he says: Even though implementators will have some good ideas, if they don't fit within the conceptual integrity, they are best left out.
Dangers of architects
- specs will be too rich and will not reflect practical cost considerations. A real danger.
- architects will get all the fun and shut out inventiveness of implementators. Brooks argues that implementation is fun too per previous arg.
- implementors will sit idle until specs become ready. Can wait to hire the implementors.
Second System Effect
First system tends to be small and clean. Knows he/she doesn't know everything and goes slowly.
As the system is built, new features occur to them. They record these ideas for the "next system."
With the confidence of having built the previous system, the programmer builds the second system with everything. Tendency is to overdesign. Cites the IBM 709 architecture that is an update to 704. So big that only 50% of features are used.
Another version of the effect is to refine pieces of code or features from old system that just aren't that useful anymore.
TJP: I tend to consider the next system to be functionally exactly the same but with a much better implementation. A few new features are ok. Actually ANTLR is less functional that old PCCTS!
To avoid can have concepts like feature x is worth m bytes and n ns of time.
Managers should hire chiefs that have at least two systems under their belt.
Communication in large project
How to communicate? In as many ways as possible.
- Informally; telephones and good idea of worker relationships.
- TJP: nowadays programmers use instant messaging a lot.
- Meetings; Regular project meetings, with teams giving briefings. Smoke out the little misunderstandings. Good way to check to see if you all have same ideas.
- Workbook; formal project workbook must be started.
Brook's Rules
1. A program is not a product nor system
2. Adding programmers to fix a delay only makes it take longer
3. Plan to throw one away, you will anyway. This book is ancient, but he says The only constancy is change itself and plan the system for change, which could come straight from the extreme programming books.
4. Second system affect: overdoing new feature list to overcome weakness in first system.
