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.

Extreme Programming Installed

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2000 Addison-Wesley

Chapter 22

Summary:

Discussion:



Chapter 23

Summary:

Discussion:



Chapter 24

Summary:

Discussion:



The Mythical Man-Month

Reference:
The Mythical Man-Month
Frederick P. Brooks, Jr.
1995 Addison-Wesley

Chapter 4

Summary:

Discussion:



Chapter 5

Summary:

Discussion:



Chapter 6

Summary:

Discussion:



The Inmates are Running the Asylum

Reference:
The Inmates are Running the Asylum
Alan Cooper
2004  Sams

Chapter 3: Wasting Money

Summary:
Deadlines in the software development business are not like deadlines in other professions.  There is often pressure to ship a product on the estimated date of completion, regardless of if the product is truly finished or not.  Many managers compensate by setting a deadline much earlier than when they expect the product to be completed.  As it turns out, a quality product that ships late will most likely be quite successful.  Programmers are more or less in control of what features are implemented in a product, but features are not necissarily good.  A mistake that gets made with multiple iterations is that if someone keeps releasing poor versions of a product, fewer and fewer people will come back to try the latest revision.  Bad software ultimately leads to higher costs, either through increased maintainence or technical support.  Prototypes are valuable, but should be used as a tool to see how the product will work, rather than as a foundation for the final product.

Discussion:
This sounds like a repeat of the software engineering class I took last semester.  I must admit there have been several occasions over the past few years that I felt an assignment had an unreasonable deadline set, and I wonder if the professors were simply being unrealistic or if they were giving us less time that they anticipated it would take.

Chapter 4: The Dancing Bear

Summary:
 Many times, people will be satisfied with a product simply because they don't know that a better alternitive exists.  People are presented flashy products with many options, but these products may not be able to do any one task particularly well.  Many current products follow current norms because it's the way it has always been done, instead of developing features that are useful to the user. 

Discussion:
While I agree that there are improvements that can be made in product development, but some of Cooper's criticisms seem a bit unfair.  Some of his criticisms seem to hindge on an omnipotent programmer who can forsee all possible ways that a product will be used, but is too lazy to implement them.

Chapter 5: Customer Disloyalty

Summary:
Desirability is an aspect of design that increases a product's likability, but is not necissarily needed.  Desirability generates customer loyalty, ensuring repeat business.  A lack of customer loyalty will hamstring a company over the long term.

Discussion:
Customer loyalty is very important and can help drive other peoply to try a product on the recommendation of their friends.  I thought the comparison of Apple, Microsoft and Novell was interesting, and I will be interested to see how things develop in the future.

The Mythical Man Month

Reference:
The Mythical Man Month
Frederick P. Brooks
1995 Addison Wesley

Summary:
Ch 1 -
When people make the claim "I could write a program that does task X better than what is commercially available," they are probably right.  However, they don't take into account that they are programming something for one particular system, and that to make it viable for multiple platforms it must be generalized and maintained.  Programming fulfills a desire to create things that are useful to many people, and it provides a sense of fulfillment.  However, a byproduct of the way programming works is that it has to be perfect, a task which is not necissarily required in everyday life.  While "good enough" will suffice in most situations, one error can bring an entire program crashing down.  In many cases it seems like programming is a mire where ideas get trapped due to the darious problems associated with it.

Ch 2-
Despite the fact that many programs end up limited by amount of time put into them, programmers remain optimistic.  We always assume that "it will surely work this time" while all evidence points to the contrary.  Programming is not like other tasks: one simply cannot accurately estimate how much time will be needed to complete a project based on its size and the number of people working on it.  In fact, adding more people to a project can often increase the amount of time needed to finish a product, as each new person assigned must be brought up to speed.  While the development of a program may be constrained by a customer's schedule, the completion of it is certainly not.  In the end, most program developments that go awry do so because of a lock of calendar time than any other reason.

Ch 3-

Discussion:

The Design of Future Things

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2000 Addison-Wesley
Summary:
Pending
Discussion:
Pending