Programming
	Unix is written in C, is a big C program, comprised of many programs
	Unix Sys Admin is the mangement of these programs and its environment

Programming and computers are fun
	We are usually optomists (get things done quickly and not have problems)

Troubleshooting/Debugging
	Syntax rules (literally - both noun and verb)
	Dependence on other programs/modules
	Bugs are small and hard to find
	The last bugs are real hard to find and route out
	Some techniques and programs fail - destroy them

Good things take time
	Cost varies with the time and number of men, progress does not
	Men and months are interchangeable ONLY when a task can be
		partitioned amoung workers with NO communication needed
		between them.  Picking cotton is linear (more men, more cotton
		picked), programming is not.
	It takes 9 months to make a baby no matter how many women are
		assigned to the task
	If a task is partitioned but needs communication, the effort of 
		communication must be added to the total time to finish
	Training and communication add more time to a projects timeline
		n(n-1)/2: 3 people vs two - 3 times the communication
		4 people need 6 times more communication as do two
	Adding more men lengthens the process - not shortens it

Good programmers = good quality code and good speed
	Small projects - need a few good men
	Large projects - need many good men, but now have overhead of 
		communication and training
		Break up into small teams separated by functions/tasks

Specs and docs - do them
	Use centralized soft copies
	Keep them up to date
	Use the docs!

The tower of Babel
	It fell due to lack of communication (languages)
	They had: a clear mission, manpower, materials, technology

Size of programs
	Scope it out and spec it out
	Avoid scope creep (adding new functions before a release that are
		not part of the orginal/agreed-upon spec)

Throw away
	Get rid of unneeded functions
	Get rid of unneeded programs
	Modify and change whenever needed

Know your tools and use them
	Debugging, compiling, source control, modeling, etc

Keep to your milestones
	Do not miss a milestone
	If you do, know why you missed it and adjust EARLY before it ripples 
		and then cripples	

So what is a mythical man-month anyway? Consider a moderately complex software application from the early microcomputer era, such as the primordial version of Lotus 1-2-3, Ashton-Tate dBASE, or Wordstar. Assume that such a program might take one very smart, highly-motivated, expert programmer approximately a year to design, code, debug, and document. In other words, 12 man-months. Imagine that market pressures are such that we want to get the program finished in a month, rather than a year. What is the solution? You might say, "get 12 experienced coders, divide up the work, let them all flog away for one month, and the problem will be solved. It's still 12 man-months, right?"

Alas, time cannot be warped so easily. Dr. Brooks observed, while he was managing the development of Operating System/360 (OS/360) in the early 1960's, that man-months are not -- so to speak -- factorable, associative, or commutative. 1 programmer * 12 months does not equal 12 programmers * 1 month. The performance of programming teams, in other words, does not "scale" in a linear fashion any more than the performance of multi-processor computer systems. He found, in fact, that when you throw additional programmers at a project that is late, you are only likely to make it more late. The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees.

When you stop to think about it, this phenomenon is easy to understand. There is an inescapable overhead to yoking up programmers in parallel. The members of the team must "waste time" attending meetings, drafting project plans, exchanging EMAIL, negotiating interfaces, enduring performance reviews, and so on. In any team of more than a few people, at least one member will be dedicated to "supervising" the others, while another member will be dedicated to housekeeping functions such as managing builds, updating Gantt charts, and coordinating everyone's calendar. At Microsoft, there will be at least one team member that just designs T-shirts for the rest of the team to wear. And as the team grows, there is a combinatorial explosion such that the percentage of effort devoted to communication and administration becomes larger and larger.

"The Mythical Man-Month" is, of course, about substantially more than, well, man-months. Many other concepts and chapter titles found in the book have also made their way into computing jargon and folklore, such as "the second-system effect" and "ten pounds in a five-pound sack" and "plan to throw one away." Brooks also addresses design issues, interfaces, specifications, tool-building, and debugging techniques. He was an early proponent of cross-compiling and simulation (when the OS/360 project started, there were as yet no fully-functional implementations of the hardware).