Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jplindstrom (594)

  (email not shown publicly)

Journal of jplindstrom (594)

Friday May 16, 2003
12:51 PM

The Mythical Man Month - notes 1

[ #12254 ]

A couple of books finally arrived yesterday. I started reading The Mythical Man Month, mostly because I've heard from so many different sources that it's a must read. And after three chapters, I can only agree...

So here are the key observations as I see it. Mostly so I'll remember the important parts myself :)

Feel free to chip in.

1 - The Tar Pit

Large scale programming is different from programming in the small. It requires a lot more non-programming stuff to be finished, like testing, documentation, integration etc.

"Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program."

2 - The Mythical Man Month

We are bad at estimating, which at heart is based on the false assumption that all will go well.

Programmers are optimists.

The incompleteness of our ideas only become evident during implementation. Practice is important for theory.

For any single task, a bad estimate isn't so important. But tasks add up, and in sequence they are very unlikely to conform to the total estimate.

Tasks can be implemented in parallell only if they are independent and require no communication effort on the part of the designers/programmers. If not, the communication effort adds overhead which may overcome the effect of more people.

We must have courage to stand by our estimates, in spite of outside pressure. "The urgency of the patron may govern the scheduled completion, but it cannot govern the actual completion."

Adding manpower to a late project makes it later.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • MMM is definitely a very good read, and makes a large number of important points, which many people doing project management miss. (And many people who don't realize they're doing project management miss) I'll add to your list two more books you should read--The Limits of Software, and The Inmates are Running the Asylum.
  • by chromatic (983) on 2003.05.16 14:04 (#20211) Homepage Journal
    The incompleteness of our ideas only become evident during implementation.

    That's why the agile methods [] prefer to deliver software early and often. The sooner you can get to the implementation, the sooner you start getting feedback from the code and the customer about what's really going on.

    That's not appropriate in all situations, but it works for a great deal of the modern programming world. Treating every project as if it were a massive engineering project hasn't done the software world many favors.

    • This is my experience too. Having business analysts dream up requirements without touching base with the nitty gritty details of reality can lead to the most complex and convoluted designs.

      The most annyoing thing with that is that as requirements are added to an inconsistent model, it's impossible to incorporate them with the existing solution without working around previous bad design desicions, which were possibly forced by other bad desicions etc, etc. It inevitably leads to a fragile and strict set of