The Mythical Man Month

Reference:

The Mythical Man Month

Frederick P. Brooks, Jr.

1995 Addison-Wesley

Summary:

Ch. 13 - A fair portion of bugs can be eliminated through the correct implementation of a design.  A top-down design can reduce the temptation to apply a cosmetic fix to a faulty design instead of scrapping it and starting anew.  Additionally, the control structures of a program need to be seen as such, and not as individual branch statements.  Methods for debugging components has evolved over the years.  Debugging the entire system goes faster when debugged components and test scaffolding are used.

Ch. 14 - Enough little delays in the production of a system can lead to big problems.  Concrete milestones provide a way to track real progress and determine how that progress relates to the schedule.  Bosses must know when to let a manager handle an issue and when to become personally involved.  An accurate PERT chart can help the boss determine which action to take.

Ch. 15 - Documentation is a key component of system design.  There needs to be documentation for the casual user of a system, the user who depends on a system, and the user who modifies a system.  A flow chart can act as an effective representation of program structure, but should not exceed one page in length.  An effective method in improving program documentation is to merge the program and the documentation together.  Symbolic names, labels, and statements should convey as much information as possible to the reader.  The formatting of code can improve readability, and comments in the code can be used as a vehicle for better documentation.

Discussion:

Ch. 13 - Debugging is one of the most important parts of programming a system, yet it is one of the most difficult to perfect.  There are so many things that can go wrong in a system, and any number of tests will not be able to prove the absence of bugs.  Indeed, all testing can do is prove the presence of bugs, so we must do the best we can to ensure the system has high reliability.

Ch. 14 - Now that I think about it, little delays do have a tendency to add up quickly.  It is truly better to have  'hustle' and perform better than necessary, so that when a small delay does occur it has little effect on the production schedule.

Ch. 15 - Proper documentation is vital to the programmer.  Code that is poorly documented will often make sense to the coder while it is being written, yet seem like a foreign language if the same coder opens it up two weeks later to do some editing.  The disconnect is even greater when another programmer has to perform maintenance on poorly documented code.  I remember a story when one such programmer found a comment that simply read "RIP LVB."  This programmer had no idea what this meant, so spent much time and effort in tracking down the original author of the code to see if the comment contained important information.  It turned out that the author was a classical music buff, and had happened to write that particular bloc of code on the anniversary of Beethoven's death.  In short, an unrelated and unimportant comment resulted in a significant amount of wasted time.  

The Mythical Man Month

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

Summary:
Ch. 10 - The critical documents for a computer product are objectives, specifications, schedule, budget, organizational chart, space allocations, estimate, forecast, and prices.  These last three are linked together, and create a spiral that can be beneficial or disastrous to the product.  No matter the product size, a manager is wise to have the necessary project documents.  

Ch. 11 - When building a pilot system, the product manager must accept that the first version, or the pilot system, will be scrapped in favor of a redesigned version with new ideas implemented.  As such, the system need to be designed to be tolerant to change.  Even after the product is delivered, changes will be made.


Ch. 12 - People like to use personalized tools, but from a programming perspective this is not conducive to good communication.  The programmer needs appropriate simulators, compiler and assembly vehicles, program libraries and accounting, program tools, documentation systems, and performance simulators.  High level languages provide increased productivity and debugging speed. 


Discussion:
Ch. 10 - As a project grows, documentation is critical to keep track of what is where, and even what is what.  There are few things worse than having to figure out how a piece of code works because its author did not sufficiently describe it.

Ch. 11 - One of the most stressed concepts in Software Engineering was having a high threshold for change.  Possible changes need to be kept in mind throughout the development cycle, or else you end up with a monolithic program in which any minor change will cause disaster.

Ch. 12 - Having a good toolkit is a essential for the programmer.  It can make complex tasks simple, and it makes the act of programming more accessible and easy to pick up.

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: