Monday, February 28, 2011

Extreme Programming Installed Ch 16-18

Reference Information:

Title: Extreme Programming Installed
Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson

Summary:
In the 16th chapter the author briefly recaps some of things you should and should not do in XP programming. The summary of which is that your program should be well designed, well crafted, flexible, documented, tested, and meet requirements. In the 17th chapter the author once again discusses the fact that experience greatly improves how well people estimate. In the 18th chapter the author discusses the important things that should be tracked. These are resources, scope, quality, and time. The author demonstrates various graphs that can be used to track or report. The author closes with the wisdom that even though we sometimes feel like we should be recording other information, it is rarely helpful to the actual project and should therefore be avoided.


Discussion:
While I do believe that this may be the most relevant and important book we have read this semester, I am a little disappointing at how much of the later chapters seem to be a rehashing of the earlier ones. Chapters 16 and 17 felt like the exact same thing I read at the beginning of the book. Fortunately, chapter 18 did have some solid new information and was very helpful.

Sunday, February 27, 2011

Design of Future Things Ch 6

Reference Information:

Title: The Design of Future Things
Author: Donald A. Norman

Summary:
The author begins with a story encapsulating the importance of feedback in a machine. He discusses how a professor gave a presentation that ended up not working due to outside forces. However, because there was no feedback from his program he could not tell that his program was running perfectly and that the problem was elsewhere. He expands on the importance of feedback from a machine with several examples and then moves on to the question of whether technology or people should be blamed when a machine behaves unexpectedly. His answer is that there are times for both. He gives an example of two hand writing recognition machines. One performed very well or very poorly based on the words entered and gave little feedback as to what went wrong. The other used a letter by letter analysis and therefore showed what letters were being misinterpreted. He found that people blamed the machine in the first case, but in the second they could see where there letters should have been made more accurately and therefore blamed themselves. He then concludes with an explanation of natural signals and natural mappings. His example of natural mappings is that of a 4 by 4 grid stove. The panel that controls the burners are often not in the same rectangular grid as the burners themselves. This is unnatural and leads to people turning on the wrong burner even when the controls are clearly labeled.

Discussion:
I know that a lot of people in class really dislike this book, but I find myself enjoying it. While it is true that all he is doing is complaining, he gives several examples to back his complaints up and they are very entertaining. I enjoyed his description of the two hand writing recognition devices as I personally would blame the machine in the first case and myself in the second. Reading this book, I realize that I should add some sound to my existing projects. I realize that it is a fine line between a helpful sound and an annoying one, but I agree with the authors insistence that feedback is important.

Sunday, February 6, 2011

Design of Future Things Ch 3

Reference Information:

Title: The Design of Future Things
Author: Donald A. Norman

Summary:
The author begins by describing how even though loud annoying noises can be affective signals when used alone, together with other machines signals they become meaningless. He then discusses affordances followed by the communication between machines and man. He compares the situation of computers and humans interacting to bicyclists interacting with people based on there predictable movements. Next, he discusses how the dangerous path is often safer because you are far more aware of the situation. The author concludes the chapter with the example of how Cobots have a natural interaction with humans.


Discussion:
The author makes some good points. There are several devices in my own home that make signals I do not understand. As with his other book, I really enjoy the authors use of excessive examples to drive his point.

Saturday, February 5, 2011

Extreme Programming Installed Ch 7-9

Reference Information:

Title: Extreme Programming Installed
Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson

Chapter 7: Small Releases

Summary:
The author discusses the importance of and some examples of frequent early releases.

Discussion:
This seems like a more drawn out version of a previous chapter. It does have more depth and examples though.

Chapter 8: Customer Defines Release

Summary:
The author recaps about how the customer should give stories to the programmers and pick the best features based on business value and time.

Discussion:
This chapter also felt like a recap of a previous chapter. This chapter, however, was coming from the customers perspective instead of the programmers.

Chapter 9: Iteration Planning

Summary:
The author describes the meeting between customers and programmers in order to select which stories should be used for the next iteration. He then describes how programmers should sign up for individual tasks for each story.

Discussion:
The systems that extreme programming have set up seem very useful. I am curious what the rest of the book will be like.