Tuesday, February 22, 2011
Sunday, February 13, 2011
Design of Future Things
Chapter 5: Servants of our own Machines
SummaryThis 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.
Monday, February 7, 2011
Design of Future Things
Chapter 3
Summary
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.
Summary
 |
| Bicycles in Holland illustrate natural safety |
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.
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.
Monday, January 31, 2011
Extreme Programming Installed
Chapter 4: User Stories
This chapter talks about the importance of user stories. In XP, informal user stories are an essential manner in which the system gets build up. These stories are preferably written in small note cards; and they can be changed over time while adapting to customer needs. In fact, the more the story changes early in the building process, the better it is for programmers since this means that users are writing what they really mean.
Chapter 5: Acceptance Tests
When discussing testing, it is the author's recommendation that tests are run right immediately; along the same period of the related story. If the programmers get their testing acceptance tests sooner, they can make the product work sooner. One of the things that XP values is feedback, therefore it is very important to do the testing as this allows the users to know whether progress is being made and that the functions addressed in the current stories work. The author also stresses the importance of acceptance tests being automated as this allows the smallest amount of errors and facilitates reporting.
Chapter 6: Story Estimation
This chapter talks about estimating the time it takes to complete a story and how to estimate it. The author suggests that story completion times should be calculated by comparing the story to be completed to another story that has been completed and therefore its completion time known. Another technique for time estimation is based on the perfect engineering week. This techniques attempts to find out how much work can be accomplished in a week where the programmers work perfectly all day every day of the week. If there is no initial story that can serve as a reference to a new story, the author suggests implementing a spike solution, which is a made up story that closely resembles the task to be completed (yet it is simple enough that does not overload the programmers).
This chapter talks about the importance of user stories. In XP, informal user stories are an essential manner in which the system gets build up. These stories are preferably written in small note cards; and they can be changed over time while adapting to customer needs. In fact, the more the story changes early in the building process, the better it is for programmers since this means that users are writing what they really mean.
Chapter 5: Acceptance Tests
When discussing testing, it is the author's recommendation that tests are run right immediately; along the same period of the related story. If the programmers get their testing acceptance tests sooner, they can make the product work sooner. One of the things that XP values is feedback, therefore it is very important to do the testing as this allows the users to know whether progress is being made and that the functions addressed in the current stories work. The author also stresses the importance of acceptance tests being automated as this allows the smallest amount of errors and facilitates reporting.
Chapter 6: Story Estimation
This chapter talks about estimating the time it takes to complete a story and how to estimate it. The author suggests that story completion times should be calculated by comparing the story to be completed to another story that has been completed and therefore its completion time known. Another technique for time estimation is based on the perfect engineering week. This techniques attempts to find out how much work can be accomplished in a week where the programmers work perfectly all day every day of the week. If there is no initial story that can serve as a reference to a new story, the author suggests implementing a spike solution, which is a made up story that closely resembles the task to be completed (yet it is simple enough that does not overload the programmers).
Subscribe to:
Posts (Atom)