Extreme Programming Installed Ch. 16-18

Extreme programming installed
Chapters 16-18
Ron Jefferies, Ann Andreson, Chet Hendrickson
Editors: ?

Summary:


In Chapters 16-18 the authors provide a detailed list of guidelines on how to create good software. Among these guidelines are to publish progress reports frequently, take stories in order, and practice continuous design. Most of the guidelines were discussed in earlier chapters, and the authors take this time to put the ideas together into a do and don't type list. The authors also go into detail about the importance of being able to estimate how much time a story will take to implement. Although this estimation is never perfect, programmers should be able to give better estimations on the time it will take to implement stories as they become more experienced.


The authors also discuss the importance of scope. Scope should be continuously monitored to make sure that the team is not overwhelmed with stories to be implemented. The easiest way to measure scope is to use a bar graph where each bar represents the number of stories in each iteration and the shaded region of each bar represents the number of completed stories.


Discussion:


This reading is interesting because it brought together a lot of ideas that were represented in earlier chapters of the book. However, I felt that these chapters could have spent less time on the different ways to measure progress. I think that these methods, such as the bar chart, seem like common sense and do not need to be spelled out for the reader. This work can be applied to all projects, not just those that use extreme programming. Many of the guidelines fit into software engineering ideals in general, such as publishing frequent progress reports.

Design of Future Things Ch. 6

The Design of Future Things
Chapter 6
Donald Norman
Editors:?

Summary:


Chapter 6 begins by discussing the recent changes in computer human interaction. The author believes that older machines were more obvious to understand and provided natural feedback to the user. For instance, a dishwasher provides sound feedback for when it is working and when it is done. On the other hand, more modern devices are less obvious in their workings and need to be better designed to make up for this weakness. One way that machines can provide better feedback to users is to provide constant feedback to the user, even when the machine is not malfunctioning. It is also important that this feedback be natural and easily recognizable to the user. The author describes this idea by giving an example of the apple newton. The first iteration of the apple newton translated handwriting into text by looking at the entire writing as a whole whereas the second iteration looked at each letter individually. As a result, the second iteration was able to communicate more effectively with the user because it gives continuous feedback about each character rather than just giving feedback for the entire written text.


The author believes that natural, implicit, and sensible communication is the key to improving the interaction of humans and computers. The feedback to the user should be rich and complex while at the same time being communicated through a natural means. However, the output must also be easily understandable or the user will get no benefit out of it at all.


Discussion:


This reading is interesting because it goes into detail about the aspects of the communication between humans and machines. The author could have given more examples of communication that fit into his ideal communication of machines to humans. This work can be applied to several projects, including my group's project for capstone. In my group's project the user will need some sort of feedback to signal how the kinect is responding to their commands or the user may get frustrated.

Extreme Programming Installed 13-15

Extreme programming installed
Chapters 13-15
Ron Jefferies, Ann Andreson, Chet Hendrickson
Editors: ?

Summary:
In chapter 13 the authors discuss unit tests and their importance in extreme programming. The programming team should use unit tests throughout the entire development life cycle to ensure that the system is tested thoroughly. The authors also suggest using a test driven development approach which involves writing tests before any system code is written. After the system code is written the unit tests should be run to verify the correctness of the code before it is added to the code repository.

Chapter 14 discusses the importance of writing code that effectively communicates ideas. The authors believe that good code should be able to be understood easily without in depth understanding of the specific techniques or algorithms used in the code.

Chapter 15 goes into detail about code repository management practices. In extreme programming, the code repository should be set up in such a way that programmers are able to work on separate pieces of the system individually without worrying about being blocked by other members of the programming team. The authors suggest using a system where code should be unit tested in order to achieve a release candidate state, only at that point can the code be integrated with the working system code. The authors also stress the importance of rapid commits to the repository in order for other team members to get new changes more quickly.

Discussion:
This reading is significant because it goes into detail about the importance of testing and continuous integration. I believe that the authors should have gone into more detail about effectively communicating code. Especially details like choosing variable or function names to communicate the programmers ideas. This work can be applied to any programming team since it involves practices that aid in distributed development.

Design of Future Things Ch. 5

The Design of Future Things
Chapter 5
Donald Norman
Editors:?

Summary: 
In this chapter the author discusses the role that he believes automation should have in our daily lives. According to the author, automation can be extremely useful for tedious or otherwise unwanted tasks. However, the increased use of automation can also increase the amount of time that people spend performing maintenance on the machines that are performing the automation. 

According to the author, automation works best for tasks that are tedious or repetitive. To further his point he uses examples of intelligent homes show the role that automation should play in our daily lives. The author fears that intelligent homes that rely entirely on automation can lead to the inhabitants becoming dependent on the house's decisions. Instead, the author proposes an approach where these intelligent homes should seek to augment the inhabitant's lives rather that automate them. In this approach, the inhabitants would have total control over the machines while they are using them. 


Discussion:

This reading is significant because it weighs the pros and cons of automation in the home. However, I do think that the author's stance on common tasks is a little extreme. Many of the tasks that he would see to be augmented rather than automated, I would rather see automated. Other people can apply this work when they are designing intelligent homes. In addition, these ideas can be applied to software as well. For instance, software engineers could use this work to determine what software tasks should be completely automated and which ones should ask the user for their input.

Extreme Programming Installed Ch. 10-12

Extreme programming installed
Chapters 10-12
Ron Jefferies, Ann Andreson, Chet Hendrickson
 Editors: ?

 Summary:
In chapter 10 the authors disuss quick design sessions. In these sessions the programming team meets to come up with a design for tasks that they are unsure how to implement. Ideally, the team should be able to think of a design within 30 minutes and use that design to begin coding the task. A quick design session should utilize all of the programming team member's skills to come up with a solution.

In chapter 11 the authors discuss aspects of the programming phase. In extreme programming all coding should be done in pairs, with one programmer doing the actual coding and another team member watching and providing input. Extreme programming also requires the pair to write unit tests before they begin and coding on the task. This allows the pair to assure the validity of their code before they commit it to the repository for the rest of the programming team to use. According to the authors, no programming team member should assume ownership of any piece of code. Any team member should be free to modify any line of code from anywhere in the project. This encourages team members to understand the system as a whole, rather than just learning the individual tasks that they are assigned. In order to facilitate the team's collective understanding of the system, a coding standard should be established. The coding standard should address aspects of the code including commenting, capitalization, indentation, naming conventions, and so on. Commenting should not be used to explain poorly written code, rather the code should be self explanatory and easy to follow, using comments only for special cases.

Chapter 12 returns to the idea of pair programming and discusses it in detail. The idea behind pair programming is that it produces better code than is produced by two people individually writing code. Pair programming also has the added benefit of furthering the team's collective knowledge of the system since both of the team members participating in pair programming will understand the piece of code that they are coding. The team member not writing the code, the partner, is tasked with spotting errors and  giving ideas and feedback to the driver, the team member that is writing the code. The driver needs to accept feedback and actively engage with the partner in order for both members to be actively engaged in the coding process. The authors also suggest that the partner and driver switch places occasionally in order for both members to remain interested in the project.

Discussion:
The main part that I find interesting about this reading is the idea of pair programming. I have used pair programming before at work and I can attest to its usefulness. Hearing more about the advantages that it can bring makes me wish that more team projects at A&M encouraged the use of pair programming. This reading does not have any faults, however I would have liked to see more about the quick design session discussed in chapter 10. This reading can be applied to our project in capstone. Right now the team is very divided on what tasks they are assigned, which will most likely result in team members becoming the resident expert on a particular topic. If we were to use pair programming it would allow more team members to understand different aspects of the project.

Design of Future Things Ch. 4

The Design of Future Things
Chapter 4
Donald Norman
Editors:?

Summary:
In this chapter the author discusses how humans have become dependent on machines, causing humans to become the servants of machines. Humans rely on machines to do tedious jobs, while they themselves do not understand how the machine works. This leaves them to supervise the machines to make sure that the job is accomplished. This causes humans to spend a great deal of time on machine maintenance and supervision. 

The amount of supervision that machines require is further increased due to the lack of communication between humans and machines. The author suggests that machines will perform best when the humans they are interacting with receive specialized training that teaches them about the functions and details of the machine. For example, in an industrialized setting, a machine operator would be trained on how to effectively utilize any machines that he is interacting with and the machine would be able to perform its job well. However, in a household environment a machine operator would receive no special training on how to use a machine and the machine would not be able to perform its job as well. Because machines cannot effectively communicate with humans, the humans need to learn more about the machines and all of their intricacies before they can work together effectively.


The author also discusses the problem of  designing machines to have automation but not full automation. In instances where machines do not have full automation, they may return control to the operator at any time. This can be dangerous since the operator may not be paying attention or may not have enough knowledge about the situation to react effectively. The author believes that machines should either be fully automated, requiring no human intervention, or have no automation at all. Examples of full automation that the author discusses are swarms and platoons. In a swarm system machines communicate with each other to move in a common direction, while in platoon systems machines follow the direction of a designated leader.


Discussion:
I think that this reading is significant because it shows how much time humans spend monitoring and babysitting machines. It also shows the risk that having semi automated machines can pose, especially in industrialized or other dangerous areas. I think that the author failed to address the merits of semi automated systems while only addressing their flaws. This reading can be applied to many areas where humans relay on machine automation. A good idea would be to design systems around the fact that machines will be ceding control to humans in the vent of an emergency. Such systems could inform the operator about the situation and even offer guidance.

Extreme Programming Installed Ch. 7-9

Extreme programming installed
Ron Jefferies, Ann Andreson, Chet Hendrickson
 Editors: ?

 Summary:
Chapter 7 focuses on the advantages of having a short release cycle. Short release cycles allow the team to supply the customer with working builds at each iteration. This allows for the customer to provide timely and useful feedback to the programming team. In turn the programming team is able to take this feedback and use it to iteratively shape the system to the customer's needs.

Chapter 8 focuses on effectively planning release schedules. A release can consist of one or more iterations with each iteration implementing one or many stories. It is important to decide what stories are included in each release in order to increase the business value of the release while still releasing it in a timely manner. The process of determining these stories starts with the exploration phase, where the customer provides stories to the programming team and the programming team provides feedback on the stories. Then, in the commitment phase, the programming team members are assigned stories to work on and estimate how much time it will take to complete all of their assigned stories. A point value is then assigned to each story, signifying how hard the story will be to implement. Finally, in the steering stage, the customer picks which stories to implement after receiving feedback on the difficulty of each story.

Chapter 9 focuses on iteration planning, or the process of assigning user stories to members of the programming team for each iteration. An iteration planning meeting starts with the customer presenting user stories to the programming team. After the team members have heard all of the user stories, they are expected to collectively brainstorm engineering tasks. Each programming team member is expected to help generate as many ideas as possible in order to benefit the team. After all the stories have been explained to the programming team, the team members should sign up for stories that they wish to implement.

Discussion:
This section of the reading was interesting because it brought up many useful ideas, such as team brainstorming and discussing user stories with the customer. I fell that team brainstorming would help gather the collective knowledge of the group in order to help avoid as many engineering road blocks as possible. Discussing user stories with the customer seems to be critical in order to start the project off in the right direction so as to not waste any time or effort. I feel like the authors should have gone over some of the ways to provide continuous or iterative updates to the user. For example, using automated build systems to remotely update the software on the customer's site. This reading could be applied to our project proposals meetings. We volunteered for specific tasks, and determined how long each task would take. However, It would be useful to engage in a team brainstorming discussion before we begin the project.

Design of Future Things Ch. 3

The Design of Future Things
Chapter 2
Donald Norman
Editors:

Summary:

The author begins the chapter by addressing the problem of communication between humans and machines. The author does not like the fact that machines predominantly communicate to their users through loud noises or flashing lights. This becomes a problem when many machines are giving signals to the user at the same time, preventing the user to be unable to react to the machines in an appropriate time. The author suggests that this problem can be alleviated by having the machine emit and ambient sound that would gradually increase in volume as the machine gets closer to failing.

According to the author, machines should exhibit features that humans can easily identify and use. This allows users to be able to interact with machines without needing an explanation beforehand. When a user is familiar with more aspects of the machine then the machine should grant more control to the user. On the other hand, if a user is unfamilar with several aspects of the machine then the machine should have more control than the user. Users should be able to determine the balance of control between machines and themselves through the use of "playbooks". These playbooks would determine what operations the user has control over and what operations the machine should handle. Users should be able to adjust these playbooks so that they know exactly what their responsibilities are as well as the responsibilities of the machine. The machine should also display the current playbook to the user so that the user never has to guess what responsibilities they have.

The author then comments on the fact that modern machines have almost entirely removed the risk factor out of most situations. The risk component of these situations can actually make operations more safe due to the fact that operators will take less risks when there is more at stake.

Discussion:

This reading is significant because it addresses the information overload that can occur when a person uses too many machines simultaneously. This is an important problem when devices need to communicate to the user. However, I do not think that an ambient sound coming from all of the devices that I am operating is the best idea. I would prefer a system where the user is able to adjust what types of warning noises are generated in what types of situations and at what volume. I think that this reading's ideas can be applied to systems where there is a delicate balance of power between the machine and the user. Some examples may be autopilots on airplanes. The pilot should be able to see at all times what operations the autopilot is handling and what operations the autopilot expects the pilot to handle.

Extreme Programming Installed Ch. 4-6

Extreme programming installed
Ron Jefferies, Ann Andreson, Chet Hendrickson
 Editors: ?

Summary:

The authors began this section by discussing the various aspects of user stories from their creation to implementation. To begin the user story process, the programmers and customer sit in a room with a box full of index cards. Then the customer writes down a story that explains a small section of the functionality of the system. The programmers and customer then work together to refine the story by asking questions and addressing concerns. This relates back to the in person communication that is a core aspect of extreme programming.

The authors then discuss acceptance tests, tests provided by the customer to ensure the system meets all of their requirements. Programmers should utilize these acceptance tests throughout the entire development process. This will allow them to ensure that the product meets the specifications of the customer at all times. The customer should also be able to add or remove acceptance tests at any point in time. A good way to manage this process is to use automated testing, where builds are automatically run through a program that will verify that they meet the current set of acceptance tests.

The last chapter focuses on how important it is for programmers to be able to estimate the difficulty of user stories. This allows the programming team to provide useful feedback to the customer as well as plan their schedule to avoid roadblocks and keep the development process as smooth as possible. The authors recommend using a point system, where each story is allotted a certain amount of points based on its difficulty. The programmers can then set a budget on how many points they are able to complete in a certain time period. If the user stories presented to the team exceed the budget then the customer would need to remove or modify stories.

Discussion:

I like the idea of using user stories to communicate the desires of the customer to the programming team as well as the concerns of the programming team back to the customer. Often, customers want every feature possible for a low cost and a short development time. Having the team meet with the customer in person can help to encourage communication on project scope and cost from the very beginning. I wish that the authors would have focused more on the discussion of how programmers and customers can negotiate user stories. Such as what to do in certain unplanned situations where the customer refuses to modify stories. I think that the ideas in this reading could be applied to the projects that I work on where a customer is involved. Having the face to face communication at the start of a project could really help me to understand what the customer actually wants from the end product.

The Design of Future Things Ch. 2

The Design of Future Things
Chapter 2
Donald Norman
Editors:

Summary:
The second chapter continues with the idea that the main problem with computer human interaction is the lack of communication between machines and their users. The author extends this idea by explaining how most users have no idea how the machines that they are using truly work. To the user these machines just seem to work, and that leaves a communication gap between the two parties.


The author then shifts his focus to the aspects of the human brain and how each relates to machines. According to the author, the human brain can be separated into the visceral, behavioral, and reflective components. While machines are able to demonstrate visceral and behavioral components, they have not yet reached the capacity to demonstrate the reflective component. The author then explains how machines could reach the reflective level through augmentation. As a result, the machine would inherit much of the subconscious, thinking work that is generally reserved for the user , whereas the user would simply make high level commands to the machine.


Discussion:


I think that the author is doing a great job at building on his examples from the previous chapters. It gives the readings a sense of continuity and doesn't overload the reader with examples. On the other hand, this chapter seemed to be less flowing and seemed to jump around from idea to idea with little transition or explanation. The ideas presented in this chapter could be extended to improve interfaces for computer human interaction, Like the author described, there needs to be more communication between users and machines. Allowing the user to see why a machine made a certain choice would definitely be a step in the right direction.