Mythical Man Month CH 18-19

Chapter 18 was just a short outline of what the originally published Mythical Man Month had.  It went through each chapter and mentioned some of the key points.  The final chapter is about why the second Mythical Man Month edition was published.  The author speaks about some of the key points that made the book popular and why he thinks it still applies.

These two chapters were not very informative.  The author seemed to drown himself in self congratulations while he simultaneously shoved his own work and achievement further down our throats.

Mythical Man Month CH 16-17

Chapter 16 talks about how to make the software design process better and about how there is no silver bullet to the troubles of the project.  It argues that one of the biggest problems is that many companies seek to build what is already built instead of buying it on the market when they should which would be faster and cheaper.  Chapter 17 revisits the paper and the idea that there is no magic bullet.  It in fact argues that there might as well be one.  Most of this chapter is spent rebutting specific arguments.

I wasn't a fan of these chapters.  The papers seemed pretty outdated.  The second chapter was really bad in that it was just a rebuttle of many arguments that had been previously made.  The problem is that I was never part of the initial discussion so I have little stake in the issue.

Mythical Man Month CH 13-15

Chapter 13 talks about debugging and how to produce programs that work.  It highlights different ways to go about debugging the system as a whole and its individual parts.  The next chapter talks about how to deal with schedule slippage and that if the team is able to get ahead then they will have some cushion in case of an emergency.  The final chapter of this excerpt focuses on how to write good documentation with the author "showing" the reader how to write good documentation.

The second chapter of the excerpt, chapter 14, was really weird to me because it seemed to contradict the rest of the book.  For the entire book the authors had argued for the reader to make tight schedules that have no cushion but in this chapter, they argue that the team should work really hard to form a cushion.  So the question is what do they want, a looser schedule with cushion or a tight schedule with a team that is dying trying to get ahead.

Mythical Man Month CH 10-12

Chapter 10 discusses different types of paperwork and attempts to affirm their validity and necessity.  The next chapter goes in direct opposition to the XP book and talks about being ready to throw one version away, labeled a lesson learning endeavor and to plan for change in the project.  Chapter 12 talks about the tools that programmers and programming projects have and the differences between community tools and individual tools that the programmers don't share.

I liked the discussion about the tools.  I have seen many senior programmers that have their own small utilities that help them immensely.  I feel that I do this myself to a degree as compared to freshmen computer science students.  The idea that the best tool is communication and that the individual tools hamper communication was an interesting one.

Mythical Man Month CH 7-9

Chapter 7, as with the previous chapter, focuses on communication within the team and how to achieve effective communication.  It focuses on the documentation styles and keeping them consistent as well as how to effectively hold meetings.  Chapter 8 aims to demonstrate why some time estimates fail.  The author reiterates the fact that there are external problems that keep developers from seeing a 100% efficiency such as sick time, meetings, paperwork and others.  The final chapter of this excerpt deals with what the author calls, space control and how to fit 10 pounds of potatoes in a 5 pound sack.  It is the process of controlling how big modules become so that the system is not too big or not too small.

I had never really thought in terms of space control.  I have been doing it for a long time just without any real inherent thought for what I was actually doing.  The points that the author made really seem to make sense.

Mythical Man Month CH 4-6

Chapter four of this book works to demonstrate the need for specific system architects separate from the implementers.  While the author argues that implementers may have good ideas, a dedicated architect should be the one in charge of fully designing the system.  Chapter five discusses what the author calls "the second system effect."  The second system effect, as described by the author is that the second system the architect designs will most likely be over designed to compensate for the problems he or she had on their first system.  The final chapter of the excerpt discusses proper methods of discussion between the managers and the architects.  The author notes many solutions such as documentation and meetings.

I liked the idea of a dedicated architect.  I would say an architecture team would be more appropriate though to help the architect better touch on the element of HCI.  In all fairness though the book was written before the HCI field had really taken off.

The Inmates are Running the Asylum CH 3-5

Chapter 3 focuses on how software development processes waste money.  The author argues that in a lot of software development there is no clear end defined.  This causes many projects to define their completion by the ship date.  When this happens, poor software is released which isn't used and fails miserably.  The next chapter discusses, in more detail, the authors notion of what he calls "The Dancing Bear."  The dancing bear is an analogy for software that accomplishes a task that people are so relieved to see accomplished, that they don't care how badly the software accomplishes it.  The final chapter of this excerpt details customer disloyalty and more appropriately, how to get it.  Cooper argues that customer disloyalty will ultimately bring any company down eventually and that this should be avoided at all costs.

The ideas around how software development can waste money seem very well thought out and I generally agree with Cooper on this.  From reading this book in CHI, I know that I often times do not agree with Cooper but in the third chapter I really think he hit it on the head.  The number of software products that seem doomed by their schedule and lack of planning is just astronomical.  It is a very unfortunate truth in the industry.