Design of Future Things Ch 6

Reference Information

Title: Design of Future Things

Author: Don Norman

Publisher: Basic Books, May 2009

Summary
This chapter discussed the necessity of communicating with machines. Communication allows people to form mental and conceptual models that provide them with clues to troubleshoot when something goes wrong, to know what to expect next, and to allow us to experiment with the machine. While mechanical devices are generally self-explanatory due to natural indicators, the indicators are becoming more hidden and silent, making it more difficult to use machines. Because of this, it falls to the designer to reveal how the machine works to the user.

Communication, understanding, and explanation are the keys to working with intelligent agents. Feedback is necessary for reassurance if the system is working correctly, and help if the system is not working. Therefore, a good design should provide continual awareness of the system's state without annoying the user.

Feedback provides informative clues about what's happening and what we should do. It includes natural sounds (that work based on subtle differences of sound). The idea is transition to a more supportive form of interaction than confusing lights and beeps, one that guides the user to decide how to respond or to reassure them that no action is required. It has to be continuous and unobtrusive, requiring little attention on the user's end.

A bad design of communication -- confusing lights to signal warnings.  At first glance, how would you know what a light was supposed to be telling you?
Source: www.stockphotopro.com

Natural interaction includes implicit communication, natural sounds and events, understandable signals, and natural mappings between display devices and their controls. Natural signals are important to keep people aware of what's happening in their environment, just enough to provide feedback but not enough to overload the user. Some good rules for interaction were provided, including: be predictable, provide natural signals, provide a good conceptual model, and exploit natural mappings.

Discussion
I think this chapter raised some very good points about design issues and how to make systems easier to use by providing a communication channel between the machine and the user. However, I felt as if I had read this chapter before. It seems to be a mix of previous chapters in both this book and Design of Everyday Things, so mostly, it felt rather pointless to read.

Extreme Programming Installed Ch 16-18

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 16 outlined things that you should and should not do when practicing the extreme programming approach to programming. This list includes things like don't try to design the whole system before you start implementing it, don't produce voluminous design documents at the beginning, focus on communication, and don't build for tomorrow. In addition, the aspects of a good program are listed: well-designed, flexibly structured, properly documented, tested, and meeting known and documented requirements.

Chapter 17 discussed how with each iteration, experience is gained that can be put towards improving estimates of future stories. The important concepts of task estimation are listed: estimate each task that you sign up for; estimate time you'll spend working; pay attention to the actual time spent working; then evaluate how the estimation time compared with the actual time.

Chapter 18 discussed how to evaluate resources, scope, quality, and time associated with a project. This evaluation lets those people working on a project know where the project currently is, and how well it is doing. Examples of each of the indicators are provided, as well as example graphs of how to plot the actual information associated with each project aspect in order to see how progress is going. For example, to evaluate quality, it is suggested to graph unit test scores vs. time.

An example graph evaluating quality by the acceptance test scores. Source: Book.

Discussion
I find it helpful that most of these chapters were just the authors outlining the main points that readers need to know about Extreme Programming and how to successfully use it. In addition, I think it's very useful that example graphs and suggestions were provided for evaluating project progress, which is very useful to us at this point in time. Since we have been working on our group project for a while now, it is getting to the point where it would be helpful to have more of an indicator of how well we are doing and an estimate of what pace we are currently working at. Some of these graphs seem like they could be useful for us to employ to help with this.

Design of Future Things Ch 5

Reference Information

Title: Design of Future Things

Author: Don Norman

Publisher: Basic Books, May 2009

Summary

This chapter discussed the role of automation, explaining that automation is needed to eliminate the dull, the dangerous, and the dirty. However, automation changes the systems already in place, changing the way work is done, changing existing jobs, and changing necessary functions. A lot of the time, it creates more work than before, just allowing the work to be done in a different time frame than previously.

The author discussed smart homes versus homes that make people smart, describing the differences between automation and intelligent augmentation. Autonomy attempts to infer the intentions of people, whereas intelligent augmentation provides useful tools but lets people decide when and where they will use them. The author then emphasized the need to recognize possible failures.

Discussion

I found this chapter very interesting since it described the small differences between automation and augmentation. While most people think that the future holds many automated things, augmentation would be more useful in many situations since it allows user choice. I liked the discussion about the different kinds of houses, and I thought the idea of the interactive message board was pretty cool.  I think that many of the ideas that the author presented should be kept in mind when designing new technologies, such as the need to allow users to make their own choices in some situations.

A picture of the interactive message board. Source: research.microsoft.com

Extreme Programming Installed Ch 13-15

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 13 discussed unit tests, recommending that everything that could possibly break should be tested. Unit tests are automated tests, and they must run perfectly all of the time. Since code is shared, unit tests are necessary to keep the rapid pace of coding working without resulting in broken code. Tests are written from the beginning, and continually written throughout the coding process. Code is only released once all unit tests run at 100%. Tests are created before ever actually writing the code, so sometimes stub methods/objects are necessary if someone else is responsible for the unwritten code.

Chapter 14 discussed the model of testing first by intention. Instead of thinking about how to do something, the programmer should think about what has to be done. This expressed intention instead of the algorithm within the code.

Chapter 15 described the process of releasing changes. It is an important part of making collective code ownership work, so that other programmers on the team can have working code released to them in a timely manner. When a programming pair writes tests and code, once all tests are working 100%, the code should be released to the team's repository. If there are conflicts between revisions, the conflicts should be fixed on an integration machine, where the pair resolves all conflicts, makes sure all unit tests still work completely, then releases the revised code to the repository.


Discussion
This reading is interesting because it brings up some very useful concepts for programming. Unit tests seem as if they would become annoying to the programmer, always having to test every little thing before the code is even written for it. While it seems as if it would be a waste of time, I can see how unit tests would actually be very useful. It probably takes less time to write a unit test than it does to fix large errors that would come up without them. In addition, the discussion about releasing changes was informative, as we are currently using a repository for our project. Some of the suggestions, such as carefully fixing conflicts and releasing very often, are good ideas that we should probably include in our own programming practices.

Source: blog.dileno.com

Design of Future Things Ch 4

Reference Information

Title: Design of Future Things

Author: Don Norman

Publisher: Basic Books, May 2009

Summary
This chapter described the problems of automating machines. The author stated that people are becoming the servants of their machines, but that it's too late to go back to living without machines. After some new technology is first deployed, it always delivers previously unseen benefits, with problems not originally thought of. While intelligent devices can interact well with the physical world and other devices, they cannot interact well with humans.

The author discussed potential automations, such as cars that drive themselves and entertainment systems that decide what you should watch. He mostly focused on the automobile, stating that it is the most advanced area of automation that impacts our lives. The difficulty is automating the driving process while still avoiding the problem of over-automation. The author discussed cars communicating with each other wirelessly, forming swarms or platoons to travel in so that their communications help each other to travel together.

A depiction of a car communicating about an accident to other cars.  Source: blogs.cars.com

Discussion
Most of what this author seems to say is just rehashing what he said in previous chapters. I understand that repetition is necessary for understanding, but it gets rather annoying to keep reading the same things. While he did bring up some good points involving automation, he seems to be against automation in one section of the chapter, then for it in the next.  Also, the swarm of cars seems like a good idea in theory; however, when technology is capable of it, I feel that in practice it would be a horrible idea. The cars would have to be entirely automated, because I can see the unpredictability of humans causing cars to suddenly swerve out of the swarms, causing massive accidents.

Extreme Programming Installed Ch 10-12

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 10 discussed the quick design session, a technique to help programmers move forward with courage. After the story is broken into tasks, the team can proceed to test-first programming, but if more clarification is needed, a quick design session can be held. The session should only be a few minutes long, and involves sketching out the design. The idea is to understand what is about to be done, and how to implement or change the processes involved in order to achieve the task at hand.

The next chapter discussed how programming should go about being done in Extreme Programming. Paired programming is established, and each pair works on one task at a time. After completing each task, it is integrated with the existing software, all unit tests are run, then the tests and code are released into the repository to complete continuous integration. In addition, collective code ownership occurs, where code is shared and owned by all so that anyone can easily make changes to whatever they might need changed. Simple design is used when programming, and refactoring occurs often such that code is always kept simple. Finally, a coding standard must be established so that everyone's collaborative code is similar.

Chapter 12 discussed paired programming in detail, where the person programming is the "driver" and the person observing and  keeping track of things the driver can't keep track of is the "partner". The partner makes sure the driver's strategy is consistent, and the driver makes sure the partner is actively engaged. They each switch roles every once and a while. The idea is that through paired programming, better code can be generated faster.


Discussion
I like the practices put forward for programmers, such as sticking to a coding standard (ugly code gets really annoying to look at!) and having continuous integration. However, I feel that some of the ideas would just be confusing or time-consuming in practice. For example, collective code ownership is great in theory, but what if someone misunderstands how someone else's code is working, modifies it with that misunderstanding, and then either breaks the code piece they changed, or breaks many other classes because of it. It seems like it could become a major issue if that happened. Also, paired programming just seems like it would waste more time than it would gain. There are many people that when put with others, tend to just talk or get distracted, which would lead to the programmer being distracted, thus accomplishing nothing. Also, if one of the people doesn't understand what's going on, the other one would spend most of their time explaining it instead of getting work done. I do see the benefits though, where one programmer can catch the other's mistake and such, but many computer scientists just prefer to work alone.

A comic mocking the potential distractions pair programming offers. Source: agilegamedevelopment.com

Design of Future Things Ch 3

Reference Information 

Title: Design of Future Things

Author: Don Norman

Publisher: Basic Books, May 2009

Summary

This chapter discussed the importance and implications of natural interaction. Many designs incorporate the use of signals, such as beeps and flashing lights, to inform users that something has happened. This author argues that instead, designers should use natural signals that humans are already used to, such as noises that already occur with a specific process. Natural signals such as environmental sounds and lights occur within the background, making them less intrusive, and are easier to identify, as identification generally happens subconsciously.

A whistling tea kettle - an example of a natural signal. Source:  www.theburningbiscuit.com

Implicit communication is discussed, which are natural side effects that can be interpreted by others and inform without interruption or need for conscious thought. The author brings up a design problem of understanding how to enhance a sound's value while minimizing its annoyance. The author then describes affordances, or communication between the designer and the user of a product. These explain perceptions of the world, and are not fixed properties. Providing effective, perceivable affordances is important in design, since it is necessary to show how to interact with a system, and how the system might interact with the world.

Finally, the author discusses predictability and natural safety. He states that a machine should behave predictably and let the person respond appropriately, so that the two can properly work together. Also, the idea of natural safety is based on the fact that as safety is increased, people tend to take more risks. Therefore, designers need to make dangerous activities look more dangerous, while actually making them safer.

Summary

I find the idea that the safer a task is, the more risks people tend to take with it to be very interesting. In theory, making something safer would be beneficial, but it is true that people tend to get complacent when the risk is removed, allowing more risks to be taken. Also, I found the example about bicyclists avoiding walkers to be very thought-provoking. Instead of trying to avoid the bicyclists while the bicyclists try to avoid the walkers, which always ends up with both moving in the same direction and hitting each other, it makes sense to give the responsibility to one of the two. In this case, the bicyclists present more danger, and therefore should be more careful, so acting predictably allows them to take the responsibility of avoiding people.

Extreme Programming Installed Ch 7-9

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary

Chapter 7 discussed the idea of having small releases in Extreme Programming. They provide early benefits to the customer with early feedback to the programmer. Early releases allow direction to be changed throughout the project, and provides an actual, working version of the product to the customer.

Chapter 8 discussed the customer's role in product releases. It is up to the customer to control the scope of each release, and to decide what needs to be done and what should be deferred. This should be decided based on the amount of business value, difficulty of implementation, and the team's implementation velocity. The exploration phase of planning release consists of writing user stories, and letting the programmers experiment with ways of building the system. This informs them how costly the stories and features will be. From this, the project velocity can be determined, which is how many points the programmers can complete within a given period of time. Based on this velocity, stories can be selected for the first release.

Chapter 9 discussed iteration planning, where the development team plans a few weeks at a time with clear objectives and solid estimates. The customer selects work that will maximize business value and programmers agree to work on stories defined by the customer in the order requested by the customer. Planning is done in short iterations, so that tight estimations of work effort can be created. The process of iteration planning is: Customer considers business value of each story and programmers assign difficulty points with an estimated velocity, the customer prepares for the iteration planning meeting by selecting stories whose points add up to the project velocity, then the customer presents and describes stories while the programmers sign up for work and estimate tasks. This allows for discussion and understanding to take place.

An example of iteration planning, whereby tasks are associated with points and programmers sign up for tasks.

Summary

I agree that small, working releases are a good idea when programming, so that the program will always work in some way and the customer can see what's being done to make sure that the programmers have the right idea. Also, I like how in iteration planning, programmers are encouraged to sign up for stories or tasks, estimating how long they will take. When the programmers have the ability to choose what parts of a program that they work on, it encourages interest in the topic, which in turn increases the programmer's productivity.