The Mythical Man Month - Ch. 7-9

Reference:

The Mythical Man Month

Frederick P. Brooks, Jr.

1995 Addison-Wesley

Chapter 7

Summary:

This chapter uses the Tower of Babel as an example to show that even if a group has all of the manpower, supplies, and technical expertise it needs to complete a project, it can all break down in the face of poor communication.  The need for a project workbook is stressed, as it assists all members of a project in keeping up with progress and changes made.  Finally, it covers the possible heirarchies that a project may have and the combinations of producers and technical directors.

Discussion:

Since pretty much every class with group projects I've had has stressed the importance of good communication, I must assume that they are onto something.  I can certainly see the value in a project workbook, as I've used code repositories to track changes to code and data.  Quite useful, though I am guilty of not always documenting thing to the degree that they should be.

Chapter 8

Summary:

This chapter examines the vast discrepencies between the estimated and actual proctivity of large programming projects.  As a programming project grows larger, it takes exponentially more time to finish.  Estimates, however, typically do not follow the same curve.  It turns out that many estimates assume that all time will be spent coding/debugging, yet fail to take into account meetings, paperwork, illness, etc.  As a result, most of these estimates are off by a factor of two.  Data shows that a possible way to improve programming productivity up to a factor of five is through using a sufficiently high level programming language.

Discussion:

I certainly understand how using a higher level programming languate can increase productivity.  To me, and I assume most others, it is far easier to program in C than in x86 assembly, and even easier to use C++ over C.  I can also see how a smaller group is able to work faster than a large group.  I suppose a special operations group in the armed forces could be used as an analogy.

Chapter 9

Summary:

Size must be considered when writing a program.  If the size of a program or componant becomes too large, the system will suffer massive performance costs.  Thus, one must not only take into consideration how much total space is available, but how much space is available for each componant of the system.  There are several tricks that can be used to decrease the space of a program, so a programmer should be able to step back and evaluate what changes can be made if they are strapped for space.

Discussion:

When reading this chapter I had to remind myself that it was written in 1995 and that memory was not nearly as cheap as it is today.  We have the luxury of not having to consider how large a program is, but it may not always be so.  As such, we need to be able to optimize performance and efficiency of our programs.