Design of Future Things

Chapter 5

Extreme Programming Installed

Chapter 13

Chapter 14

Chapter 15

Design of Future Things

Chapter 5: Servants of our own Machines

Summary
This chapter analyzes the state of machine automation where machines are able to make certain decisions for the users. According to the author, automation poses a problem to users' freedom in several ways; since it makes them dependent on the technology at hand. Donald Norman gave the example of cars that would drive themselves or would create ad hoc networks in order to inform other cars about different events. At the end of the chapter, the author also discusses certain problems that arise from automation.

Discussion

At first I thought the article was exaggerating a little about the amount of automation present in new technologies (particularly in cars where the author places the most focus). However, after a little research I realized that the technologies mentioned in the chapter, like the camera that reads a driver's eye, are currently being implemented. I thought the part where the car is called into court was very funny, yet a little frightening.

Extreme Programming Installed

Pair Programming

Chapter 10: Quick Design Session
Summary
This chapter gives out a tip about making quick design decisions. When the programmer does not know how to implement a particular task, it is recommended that he discusses this with his co-workers for about 10-30 mins (30 mins max). After the discussion, it is time to start coding so that the coding will guide the flow of the development.

Chapter 11: Programming
Summary
The programming chapter of this book talks about the methodologies used to write software in XP. Software is written in pairs and it is integrated several times a day (acquiring the name of continuous integration). Also, the tasks' test are written first and the code of the programmers intend to make sure the tests run at 100% success all the time; this includes tests from other modules. The rest of the chapter discusses certain requirements of XP such as simplicity of code, collective code ownership, adhering to coding standards, and working weeks of 40 hours. Also, the author mentions the principles of refactoring which basically involves improving code previously written.

Chapter 12: Pair Programming
Summary
The concept of pair programming was briefly discussed in the previous chapter. In chapter 12, the author provides some details about the mechanics of this technique. In pair programming, there's a driver and there is a partner. The driver is responsible for coding, while the partner is responsible for making sure the driver is going in the right direction. This can encompass remembering names (variable or methods) for the driver, or simply making sure the code is readable. Towards the end of the chapter the author provides some tips on how to work in pairs.

Discussion
Chapters 10-12 discussed the actual programming part of the XP methodology. Its really interesting that XP encourages (or enforces) pair programming. I always thought that programming was a one-person's job, but I would not be closed minded to the possibility of working in pairs.

Design of Future Things

Chapter 3
Summary

Bicycles in Holland illustrate natural safety

Donald A. Norman talks about the importance of the natural communication that occurs between things and the users. In this chapter, he proposes the use of pleasing sounds in order to enable objects to communicate in a more natural way with the environment. However, the author also recognizes that sound can contaminate the environment. For example, objects might produce sounds that are unnatural and annoying to the users, thus creating a conflict between too much sounds or not enough of them.
Norman also describes another way of communicating: Affordances. This concept allows the machine to communicate with users in a more intuitive, more simple way than other concepts. The author expresses this fact by providing the example of tight-reign and loose-reign in horse back riding. Norman describes a necessity for users and machines to have a way to communicate goals and plans in order to achieve a certain activity. Lastly, the concepts of natural safety and responsive automation are discusses.

Discussion
I thought the chapter was a little long, yet interesting. What I really notices about the author's work is that his concept of designing new things relies a lot on the way we currently perform activities. I also think he prefer the natural ways in which nature perform activities. It would be interesting to see new inventions that take advantage of these paradigms and whether or not they would in fact be more beneficial to the users and more natural-feeling.

Extreme Programming Installed

Chapter 7
This chapter talks about the importance of releasing functioning products to the customer very often. These builds do not have to be the complete product, however they must have functionality as to allow the user to test certain aspects of the software. This will enable customers test the software in case it is not what they desired; and it allows the developers to tailor the development to meet customer needs.

Chapter 8
In chapter eight the author talks about the steps necessary to make a release. Releases and iterations are composed of three phases: exploration, commitment, and steering. The basics of planning a release consist of writing down the stories, assigning a cost to them, estimating the team velocity, and let the user pick the stories that carry the most business weight for the developers to work on.

Chapter 9
Chapter nine describes the process of iteration planner in which programmers produce tasks out of the user stories selected. The process proceeds as follows:

• The user selects the stories that he or she wants to be implemented for the iteration.
• The programmers brainstorm in order to produce the tasks required to carry out the user story.
• The programmers sign up for certain tasks.

Discussion
Chapters 7-9 describe the process required to carry out a release. It all starts with stressing the importance of releasing early and often, and it ends right before the programmers start carrying out the task necessary to produce a release.