Design of Future Things Ch 2

Reference Information 
Title: Design of Future Things
Author: Don Norman
Publisher: Basic Books, May 2009

Summary
This second chapter discussed the psychology of people and machines. The author mentioned that humans generally use anthropomorphism to apply human attributes to machines. With changing technology, the design of such machines is evolving to become autonomous or semi-autonomous, where they can create their own assessments of situations and make their own decisions. Generally, manufacturers want users to believe and trust in the designer, not questioning the machine or how it's working.

The author looked at the design of brains, comparing humans versus machine. While machines are faster at processing, the processing is much less parallel as compared to the human brain processes. Humans tend to see relationships, patterns, and similarities between objects, and generally contain common sense, while machines do not. However, both human and machine must succumb to the same worldly demands and requirements, such as the need to function effectively, reliably, and safely in the real world. To further discuss brains, the author describes the three important levels of processing in the brain: visceral (subconscious processing determined by biological heritage), behavioral (learned skills that are mostly subconscious and control behavior), and reflective (conscious and self-aware; contains analysis of past and future dreams).

Symbiotic relationships are discussed, as in considering the car+human or horse+human to be a whole system, it becomes a conscious, emotional, intelligent system with the car being visceral, the driver reflective, and both being behavioral. However, there are some currently irreplicable capabilities of humans, such as emotions, perception, and the common ground aspect that is needed for proper communication.

Discussion
The author explained many differences and similarities of machines, emphasizing his point with examples of future systems such as a refrigerator that puts you on a diet. The examples were amusing, but I could see how once the technology caught up, someone would think this was a good idea and implement it, eventually leading to some interesting conundrums like refrigerators starving their overweight owners. I like how the author provided his own opinions about how such machines could be designed to be useful and accepted by people as a whole. His opinion was that if machines suggested instead of demanded an outcome it would be better. For example, instead of the refrigerator denying access to food, it could simply suggest not to eat it, or even make fun of the person to offer some stimulation for not eating it. In addition, better communication between humans and machines needs to be established, so that if the assumptions and common factors between the two are made clear, it should be easier to actually communicate. I agree with the author's opinion.

An ordinary, non-controlling refrigerator. Source:  www.goodmanappliance.com

Extreme Programming Installed Ch 4-6

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 4 discusses user stories, which are short descriptions of the behavior of the system from the viewpoint of the user. It is the customer's responsibility to create the stories to let the programmers know what's needed in order to get the most possible value out of programming. The user story acts as a mode of communication between customer and programmer. Stories can be split or expanded upon based on the amount of time they will take or estimated complexity.

An example of a user story depicting the need for a "Search and Replace" feature in a word processor. Source: www.stellman-greene.com

Chapter 5 discusses acceptance tests, which allow the customer to know when the system works and to tell the programmers what needs to be done. It is the customer's responsibility to provide acceptance tests as part of each iteration, telling the programmers what must work and ensuring that changes to the system do not break things that already work.

Chapter 6 explains the process of estimating stories, and how long they will take to program so that customers know how much stories will cost in order to choose which ones should be completed. During the project, stories are estimated by comparing them to previously completed stories, although the time to implement a story depends not only on complexity but also how fast the team is working at that point in time. The estimation usually occurs by some neutral measure of time, such as a point system or "perfect engineering weeks." For stories that are unlike any story previously completed, the method of writing some sample code to make an estimation is preferred.

Discussion
The idea of user stories seems like a good idea for getting the customer to neatly lay out the features a system needs to have, although it may be confusing as it is unlike most methods. Acceptance tests could also be a useful feature, allowing both user and programmer to be sure that a particular aspect of the system is currently working despite any changes that may have occurred. While programmers generally find tests to be tedious and a waste of time, the customer's satisfaction should probably outweigh the programmer's speediness of programming. Besides, if the programmer is attempting to program as fast as possible, eliminating tests in order to do it, he is likely to waste more time fixing things that have been accidentally broken than would originally have been spent writing automated tests. Finally, the point system of estimating stories seems like it would be a pain. Instead, it would be nice to be able to say approximately how long the programming should take in days or weeks instead of assigning points that could be seen to have arbitrary meaning to different programmers.

Design of Future Things Ch 1

Reference Information
Title: Design of Future Things
Author: Don Norman
Publisher: Basic Books, May 2009

Summary
This chapter introduces the purpose of the book, describing examples of current and future technologies, and the problems and advantages of each. A couple examples are cars with auto-corrective steering and refrigerators that monitor food intake, providing suggestions where needed. The author argues that we need to change the way we interact with machines in order to take better advantage of them, while at the same time changing the machines to be less annoying and safer. Auto-corrective cars can be dangerous when the car acts unexpectedly, and the same goes for other technologies. The more powerful technology becomes, the more dangerous its failures in communication can become.

The author describes that the designer of a machine has the goal to create complete automation, eliminating the possibility for human error. Therefore, machines are often designed to automate many things, without considering the possibility of human error. So, when conflict or human error occurs, problems can arise. The intelligence of the machine rests with the intelligence of its designer.

The need for a symbiotic relationship is expressed, whereby machines and humans have a cooperative relationship that allows the enhancement of our lives. To accomplish this, there needs to be a more natural form of interaction that can take place subconsciously, allowing smooth communication between both human and machine. Machines will have to be able to make suggestions without controlling or annoyance, and provide enjoyment to its users. This interaction should be able to occur without significant training or skill.

HAL9000, a fictional sentient computer from 2001: A Space Odyssey.
Source: www.drucker.ca

Discussion
The author brings up some good points with his examples of technologies. In theory, many of these new automated machines can be very useful and time-saving; however, in practice, they just end up being annoying and a big waste of time. Humans enjoy the act of choice. With automation, the human is removed from the decision process, allowing no choice, as in the example of a GPS system that merely tells a person where to turn. What if they don't want to turn there? With cars that auto-correct speed or position within a lane, the auto-correction can prove dangerous rather than helpful if it takes the driver by surprise.

Because of these issues, future technology should take into account the necessity of human choice and control, and have systems designed accordingly. The need for seemless interaction between human and machine would be helpful with fixing this.

Extreme Programming Installed Ch 1-3

Reference Information

Title: Extreme Programming Installed

Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson

Publisher: Addison-Wesley Professional, October 2000

Summary

The first chapter, "Extreme Programming," discussed the basics of the extreme programming approach to project design. Extreme programming is described as "the discipline of software development with values of simplicity, communication, feedback, and courage." The chapter describes the role of various participants in the software development, including the customer (whose job is to choose what is needed to produce business value, builds stories, and specifies acceptance tests), the programmer (whose job is to estimate difficulty, design, test, program, and integrate the system), and the manager (whose job is to bring the customer and programmer together and to keep the process running smoothly). The rights of each participant are then spelled out, including such things as the right to produce quality work or to see progression.

The second chapter, "The Circle of Life," outlines the project flow process using Extreme Programming, in which the customer defines what has value and the programmers build it.

An example of the project life cycle. Source: Extreme Programming Installed.

Chapter three defines the role of the customer more definitively, arguing that the customer should be on-site full-time, in order to have more effective conversations with the programmers, leading to more satisfaction for the customer. If the customer cannot be present, someone should be there to represent them, they should be there for planning meetings, and code should be released frequently.

Discussion

Extreme Programming seems like a good idea for software development, making sure conditions are right to have high-quality, working products. For example, with paired programming, programmers have the chance to easily discuss problems with someone, and the two programmers can collaborate together to create better code than one person could have. However, this is highly inefficient. When put together, people are prone to distracting each other or conflicting with each other, leading to the result that paired programming would make programming take much longer than it would with the two people working individually. And while having an on-site customer would alleviate many problems and could lead to a highly useful product, it is very inconvenient. Most customers just want to hire someone to create a product, then leave them to it. The customer may have to lose out on valuable work time while being present on-site, making this idea a good one, but an impractical one.

Introduction

Name: Shena Hoffmann

What will you be doing after graduation? Going to graduate school to receive a Master's degree in Computer Science.

Computing interests: Artificial intelligence, information retrieval

Computing strengths: C++, Java

What was your favorite computer science project that you worked on? A Chinese Checkers game with an AI that could be played against. I liked it best because, while it was a pain to program, when it was all done we could sit and play it as a reward.

What was your least favorite? Systems programming for 313, because there was little documentation to help, and it never worked right.

What do you see as the top tech development of the last 5 years? Easily-accessible touch screens, because not only are they fun to play with, but they have so many useful possibilities as to what they could be used for.

Insight into management/coding styles: I don't like to manage, but I will do whatever work I'm assigned and have it done on time. I like to keep my programs nice and organized, with comments and appropriate tabbing.