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.

Extreme Programming CH 22-24

Chapter 22 deals with handling deficits.  These are problems found in an already released iteration of the program.  For most deficits, the book advocates fixing them in the next iteration, however, if a deficit is too extreme it may need to be fixed immediately at the expense of a story that was supposed to be worked on immediately.  The next chapter is simply a conclusion of what has been discussed previously in the book.  The final chapter of this excerpt deals with teams having trouble adopting the XP method and why some groups are more resistant to the changes that adopting the XP method would entail.  They mention things such as programmers being set in their way or managers that are very draconian.

The first chapter was the primary meat of this excerpt and therefore requires the most attention.  Handling problems is often overlooked in the planning but it is important to know how to address them.  I liked the idea of simply making them into a story.  This is what we would typically do when I worked at Cisco and it seemed to work very well.  The real problem would only occur when serious errors were found that required us to update previous iterations.  Doing this would throw the entire system out of whack and take another iteration to get things back on track.

Extreme Programming CH 19-21

Chapter 19 deals with directing a project and handling the stories as they come in.  Chapter 21 deals with tracking the iteration.  It suggests assigning a person to the role of tracker.  The tracker would go from programmer to programmer asking them how they are doing on their assigned tasks and how long they think they have left.  The final chapter of this excerpt is about steering the release.  The chapter deals with how the programmers can make sure they are reaching the minimum requirements for a release before they actually go to release.

All three chapters were about steering.  It seems like a pretty important aspect of a project but these chapters, like others before it, had somewhat of a no duh factor.  It seemed like a lot of what they talked about should have been pretty easy to come up with on your own.  I did like the idea of having a tracker though.  It seems like having a tracker other than your direct boss would be a lot less stressful.

The Inmates are Running the Asylum CH 1-2

The first chapter is spent making the obvious argument that everything now days is becoming a computer.  From an alarm clock, to a camera, to an airplane, to even a warship, Cooper argues that everything has been crossed with computers, therefore turning the original item into a computer itself.  The second chapter deals with cognitive friction and how computers have so much of it.  For example, Cooper uses the argument that a violin, while complex, is easily understood by looking at the device.  Computers on the other hand, have an array of buttons that may do something different based on what state the computer is in.

I read this book once in CHI and I still have the same thoughts.  While Cooper brings up some good points, most of his points seem fairly outdated.  Computers now days have become quite stable.  For example Windows 7 has never crashed on me.  This is very different from when the book was written and computers would crash regularly.  The same ideas of making software easier to use are getting pounded to death in this book and I have trouble differentiating this book from all the other books that preach for better software.

Mythical Month Month CH 1-3

Chapter 1 of "The Mythical Man Month," gives some insight into the problems faced by some development teams.  The primary point made here is that while small teams can be organized easily, for large systems the effort is much more advanced.  The second chapter attacks some fallacies in planning such as programmer optimism in how long a task will take, the idea of a man month not mapping to more work being done, and that testing will take much more time that typically alloted.  The third chapter focuses on how to organize small teams that will make up the larger system team.  The authors argue that one person can be in charge of a small team, therefore only the leader of the small team must be filled in to the larger idea instead of everyone on the project.

I liked the fallacies.  I find that I, myself, many times fall prey to the optimism fallacy in planning.  The small teams chapter seems like it really dated the book.  I found it interesting how much of an importance the author placed on the secretary.  I have worked at a few companies and I don't remember anything but the highest employees having a secretary.

Design of Future Things CH 6

This chapter focuses on communication with machines.  He starts the chapter by talking about the failed Apple Newton from the 80's.  He describes how the tablet's hand writing recognition scheme failed because it would provide input that the user could easily blame on the tablet and not on the user.  He pointed out that if the system had worked such as instead of recognizing "hand," it recognizes "nand," the user would be more apt to blame themselves for not putting the stem on the h high enough.  Norman then discusses mappings and representations of data.  He discusses how people interpret artificial data and how better representations could be made.

I really liked Norman's discussion regarding the Newton.  I had never thought of that.  Unfortunately it made me think completely opposite of his intention.  Norman wants designers to design systems that just work but a lazy designer could easily design a system that puts the flaws onto the user, meaning that if something does go wrong, the design would cause the user to think its their fault.  This could effectively get designers off the hook for designing good systems.