The Design of Future Things, Chapter 4

Reference Information
The Design of Future Things
Donald A. Norman
Basic Books, New York, 2009


Summary
In chapter four, entitled "Servants of Our Machines", the author emphasizes how machines have come to dominate our lives to such a degree that we spend much time keeping the machines happy instead of the other way around. He claims that we have become entirely dependent on machines for our well-being and on their ability to do harder work or more tedious jobs. The crux of the problem is that most people do not understand how the machine actually works, leaving them in a position where they must keep the machine working or the job will not get done. To make matters worse, the machines need constant maintenance and supervision so that their human masters in effect become the servants. The constant march of technology will not, in the author's opinion, help the matter at all since each new advance will solve known problems but introduce new and unforeseen problems.


Intelligent machines do a reasonable job at interpreting and interacting with the physical environment and other intelligent agents, but come up short in their attempts at human interaction. Machines are especially good at performing well-defined tasks where they do not have to interact with anything outside of a small environment. They can also serve effectively in industrial uses since the human operator is forced to learn all of the intricacies of the system, in effect changing the person to suit the machine. In locations where people might interact with machines without any special training, such as the home, the machines fall flat since they are incapable of effectively communicating. To alleviate the gulf that exists between humans and machines in communication, machines must be taught "social graces, superior communicative skills, and even emotions".


Designers must avoid the fault of over-automation without achieving full-automation. That is, devices that manage certain parts of an operation while leaving other parts for their human operators. This sort of design is dangerous since the system might cede control unexpectedly fully back to the user, who will inevitably will not be able to react effectively. The primary cause of this is human inattentiveness when the machine is doing a good job at automation since their input is unnecessary. This is because a person's situational awareness and vigilance degrade as long as the machine continues to operate well without human intervention. Ideally, the author argues, automation should be all or nothing: either full automation or no automation at all.


The chapter also introduced artificial swarms and platoons. The idea of a swarm is to fit many agents in a small space and have them all go in a general direction while each makes sure that he does not collide with any others. These systems would allow for many more vehicles to be able to drive on the same roads since the swarms can pack the vehicles much closer. This is achieved by having all members of a swarm communicate which direction is desired. Platoons, on the other hand, work by having everyone follow a leader and would be much simpler to implement.


Opinion
By far the most interesting idea presented in this chapter is that of swarms, particularly of vehicles. If such a system were to come to fruition, transportation could become enormously efficient. About becoming slaves to machines, I agree and disagree with the author. The author wants full automation, where the human gives almost no input and the machines basically take care of everything. This is fine for industrial environments, but at home I would rather have much more control over my environment instead of ceding every decision to machines.

The Design of Future Things, Chapter 3

Reference Information
The Design of Future Things
Donald A. Norman
Basic Books, New York, 2009


Summary
Machines currently fail to effectively communicate with humans, because they rely on signals such as loud, annoying sounds and flashing lights. These may be able to indicate that an error has occurred, but once there are many devices in one location all vying for attention, it will become impossible to tell what is going on. This is where natural interaction comes in, by moving the signals into the subconscious background where they are then permitted to communicate unobtrusively with the users. In the case of sound, this can be accomplished by transforming the signal into the ambient plane where the current state of the machine can be indicated by varying the ambient noise or making in louder and more obvious when something is starting to go wrong. By giving the user indication of eminent failure, the user can be prepared to take manually control which avoids the main pitfall of automation: the unexpected failure of the machine. The ambient sound should be provided by a naturally occurring component of the system, if possible. Another way of communicating to the human in a subtle way is by suggesting or tempting the user into choosing the preferred or safest setting by various means.


The author claims that humans know what to do when encountering a new object because they recognize features that the object contains that they have experienced before. He defines this as affordance, where the relationships between object and agent are enumerated. To take advantage of this intuition, devices should exhibit these features so that people may instantly identify what the machine's purpose is and how to use it, even without having to be told anything about it. To make the effect even more natural, the level of control exerted by intelligent machines should vary depending on the affordances of the human operator.


One way to control the machines would be through what the author terms "playbooks". The user can select a playbook that determines how much control the person has and how much the machine does, and allow the user to tweak exactly what the machine should do. In addition, the machine should show which playbook it is currently operating under while it is in full control so that the user knows what to expect and so he can change the playbook, if so desired. An intelligent machine should not, however, attempt to predict what a user might want since the user will then be left trying to predict what the machine might do. To alleviate this, the machine should be as predictable as possible and begin intelligent operation only after having been given instructions by the user.


Counter intuitively, the author suggests that danger may actually aid safety since people tend to take less risks when what they are doing is considered unsafe. This effect is called risk homeostasis, which may need to be implemented purposefully since modern technology has attempted to remove any feedback altogether.


Again, the author proposed his symbiotic relationship being the ideal form of human-machine interaction. This time he used the example of Cobots and Segways to show that machines can respond so effectively to human actions that the user may become oblivious to the fact that he is still using a machine.


Opinion
The most interesting points raised in this chapter were the ambient sounds from machines to indicate state and the apparent correlation between danger and risk taking. Like most people, sometimes I am already overwhelmed by the amount of information being generated and being annoyingly broadcasted to me by my devices. The idea that things can be made more dangerous to make them safer is intriguing, but I believe this can only be restricted to such things as transport since, as he mentioned in the chapter, few people want to purchase something that may begin to act unsafe of its own accord.

Extreme Programming Installed, Chapters 7-9

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000


Summary
Chapter seven emphasizes the need to have a short release cycle to get functioning iterations to the customer for real-world use as often as possible, even if the functionality provided is just a subset of the final features list. These short releases allow for quick feedback and for the customer to change their mind or refine their vision so that the programming team can improve and deliver software that more meets the customer's needs. This in turn leads to more useful software, which increases business value. The authors propose that on many complicated systems that are intended to replace an older functioning system, the replacement can take place over time in a piecemeal fashion. This can be done by implementing the new GUI first and tying it into the older system and by delivering functionality in the form of discrete programs that can interact effectively with the older system.


The eighth chapter discusses how the customer goes about defining what makes it into each release. At the basic level, each release is comprised of one or more iterations, each implementing many stories. Therefore, someone must decide which stories to implement in each iteration so that the business value of the upcoming release can be maximized. The process involved with feature selection is done by the customer and consists of three phases: exploration, commitment, and steering. In the exploration phase, the customer writes out the stories that he thinks will increase business value the greatest and the programmers dabble with how to implement these ideas. During commitment the programmers are given these stories and estimate the amount of work required for each, while the customer fields questions and breaks up stories into smaller ones if necessary. The cost assigned to each story is a point value; the team can estimate their work rate in points then, as they become more experienced, they can provide a solid number for the amount of points that can be done per week (called project velocity). Finally, in the steering phase the customer picks which stories to implement based on business value and current velocity.


The ninth chapter concerns iteration planning, which is the process of taking the already decided-on stories and having the programming team break them up into engineering tasks and then having each programmer sign up for work to do. As stated above, each release is only a couple of weeks apart so the tasks need to be broken down small enough to be accomplished in these sort of time-frames. Each team member is expected to understand each story presented and to participate in the brainstorming of engineering tasks. This is the idea of collective ownership, where any programmer has the ability to step in and work on any part of the system. However, it is still optimal for one programmer to take responsibility for all the tasks that make up a story to ensure that it is implemented efficiently.


Opinion
These three chapters were only elaborations on the processes already outlined in the previous chapters. The only interesting part was how the programmers were allowed to choose their own assignments, and to share them with others if need be. Again, I have concerns that the programming team will almost certainly over-estimate their abilities and lead to conflict with the customer over the amount of work being done.

The iterative process

Extreme Programming Installed, Chapters 4-6

Reference Information
Extreme Programming Installed, Chapters 4-6
Jeffries, et al
Addison-Wesley Professional, 2000


Summary
Chapter four describes the process for using stories to drive the iterative development process. User stories are short explanations of the desired functionality of the system. They are written by the customer for the programming team, describing at most one major feature that is desired. The story writing process starts with the customer and programming team in the same room, and a box of index cards. The customer should then write out a story on each card while the team asks questions, causing the customer to refine the story until the team is in complete understanding. The conversation generated between the customer and the team is the critical element of the process, since this type of face-to-face meeting is much preferred to email and phone calls. The stories should be whittled down, or broken up into separate stories if need be, so that they should only take a week or two to implement for a programmer.


Chapter five covers the topic of acceptance tests, which are the tests provided by the customer to ensure that all of the requirements are being met. The tests should be as thorough as possible to ensure that no major bugs make it to the actual release version. Testing should be a key part of the development process, with testing going on from the very beginning so that any bug introduced can be quickly fixed before the programmer forgets the details about the offending code. To facilitate this constant testing, it must be automated from the beginning so new tests can be added throughout the development process without difficulty. The customer must provide the acceptance test for a feature being implemented in an iteration by around the middle of that iteration to ensure that it gets the necessary amount of testing. 


Chapter six explores how programmers can estimate the cost of a story, in terms of programmer time. Accurate estimates allow the customer to choose exactly what they would like in each iteration while also keeping the development process running smooth. At first judge time by "perfect engineering weeks", which are ideal working weeks with no interruptions. Then, assign points to this allotment of time so future reckoning of time is in an abstract point form instead of real time so as to prevent demoralizing the programmers. Once these baseline estimations have been assigned points, all future stories can simply be compared in difficulty against already completed stories to estimate cost (i.e. if it is twice as hard, double the points). To give the customer a "budget" for features, use past performance in points per iteration to judge how much may be completed in the next.


Opinion
We have had to use the storyboarding technique in a software engineering class, but we lacked specifics and experience on how to put it into motion. We mostly made mistakes coming up with story size, and chapter four made it clear to me exactly how large projects should be. The author should have, in my opinion, explained the exact difference between unit and acceptance tests, since he clearly differentiates them but gives no reason for this.

Using index cards to write stories on

The Design of Future Things, Chapter 2

Reference Information
The Design of Future Things, Chapter 2
Donald A. Norman
Basic Books, New York, 2009


Summary
The second chapter discusses the gulf that exists between machines and humans in understanding and communication. One aspect of this problem is the current design of supposedly intelligent machines, which operate "automagically", or without the user's knowledge of how they work. This is well enough as long as the machine functions correctly, but when something goes wrong the user is frustrated because they have no idea how to fix it. A fundamental barrier to communication between humans and machines is the lack of "common ground". Machines communicate by strict rules, whereas humans are much more flexible. To help alleviate this problem, the machines should merely suggest that the user take its recommendation and provide the user with multiple options so that the user may better understand what is happening.


The author divided the human brain into three basic levels:

1. Visceral - subconscious and automatic, biologically inherited
2. Behavioral - learned skills that become subconscious
3. Reflective - conscious, self-aware part of the brain

Machines have yet to reach the reflective level, but the author imagines that they soon will. The outline of brain function serves the purpose to show how humans may be augmented with machines that can take over the lower level functions, and perhaps start creeping into the reflective level. That is not to say that machines will think for you, but on your behalf.

The author likens this again to the horse and rider example from chapter one. While a person is riding a horse, the horse handles the actual movement and avoidance of immediate objects on the visceral level. Both the horse and rider learned how their relationship should function, making both of them act on the behavioral level. The rider operates at the reflective level in deciding where to go; however, the horse can also operate at this level if it decides it not longer wishes to bear the rider. The subconscious level of the interactivity between the horse and rider is what the author termed a symbiotic relationship in chapter one. The idea of augmentation is applying the same principles of horse and rider to the relationship between driver and car, where the car begins to assume much of the subconscious work, leaving the driver to simply decide where to go (or even be told where to go if the machines reach the reflective level).

Opinion

The author simply elaborated on the previous chapter and defined the relationship between machines and humans with a little more specificity. I disliked how the chapter contained various, seemingly unrelated topics; for example the augmentation and automagical discussions do not seem to be related enough to be in the same chapter. His description of the lack of common ground was useful, and the refinement of the symbiotic relationship now took a satisfying turn toward explaining how and why it could be achieved.

Deus Ex is a game that explores what an augmented future could bring

Extreme Programming Installed, Chapters 1-3

Reference Information
Extreme Programming Installed, Chapters 1-3
Jeffries, et al
Addison-Wesley Professional, 2000

Summary
The first three chapters explained the desired relationship between customer, manager, and programmers in extreme programming. The most critical aspect of these relationships is that the customer, or its representative, should be on-site with the programmers to field questions and provide immediate feedback on each new release.

The customer should be involved in the planning process by selecting which features that they would like to be implemented, and in what order. These features are written out in the form of stories, explaining exactly how the customer wishes the product to work. The customer estimates the cost of each feature in time to implement and relates this to the customer, who can then decide which features he wants in the next release so that the business value of the program will increase the greatest. The programmer should refine his estimations based on past performances. This is what the book refers to as "the circle of life", and is critical to the extreme programming process.

To effectively implement this practice, the programming team must adopt certain ways of working. These include sharing the ownership of code with everyone on the team, writing code in pairs to ensure quality, using unit tests, using tests defined by the customer, and a continuous design paradigm to go with the small release cycle.

The manager's job is not to be involved with the design and implementation of the software itself, but to remove obstacles from the path of the programming team and to organize planning meetings. In addition, he should ensure that the customer's needs are being heard at the meetings, and also prevent outside influences from affecting the team and dispense with rewards or provide compensation to team members.

Opinion
The topics in the first three chapters seem to relate to a programming philosophy that I am already familiar with: Agile development. The system proposed here seems like it would help produce software more efficiently and with higher quality. My main concern is the idea of only designing the program for each iteration. This seems like you could end up with significant difficulties if the customer introduces a story that is even moderately different than what the program was designed for. Other than this, I believe this would be an effective system.

A picture symbolizing the customer attending the meetings

The Design of Future Things, Chapter 1

Reference Information
The Design of Future Things, Chapter 1
Donald A. Norman
Basic Books, New York, 2009


Summary
The first chapter focuses upon machine-human interaction and the difficulties that it faces. The author says that the main problem between humans and machines is lack of understanding, on both sides. He likens this to two monologues, where the machine and person are both issuing their commands but without true interaction and understanding. This leads to frustrating and dangerous situations because the user may not understand how or why the machine is acting the way it is since communication between them is so ineffectual.

Norman believes that a symbiotic relationship between man and machine could be possible, and is the ideal relationship. In this state, the person can receive feedback from the machine on an unconscious level about what the device 'thinks' about the situation. The machine, in turn, should also accept input from the user in non-explicit (i.e. by user commands) ways such as trepidation on the user's face. The best example of this given in the chapter is the way horse and rider both respond to each other, with decision making fluctuating between them depending on the situation.


Opinion
The chapter's purpose was to engage the reader's interest in the problems faced in machine-human interaction. What I took most from the chapter was the idea of the symbiotic relationship and the horse and rider example, which makes the idea of what could be possible very exciting. The applications of this seem rather limited to very few things, and not usable at all for the typical computing platform.

Introduction

Hello, my name is Andy Fields. Welcome to my capstone blog!

I guess I'll get right in to the required talking points:

1. After graduation I plan on finding a job in the Austin area, preferably in a smallish start-up company. The one thing I can't stand is the rather depressing corporate culture of larger companies. And besides, I think I will stay motivated better in the highly volatile world of the start-ups.
2. My computing interests focus on systems design where large complicated systems need to be designed so that its many parts all function together smoothly and hopefully in a near optimal manner. Naturally, the only system of the requisite size and complexity that I can work on at the moment are game engines, which I have written a few myself.
3. My strengths are focused around low-level programming using C. It seems to me that less people are interested in this area but there is still a significant demand for these skills, which is a good situation for me. Along with this, I feel that I have the useful ability to break large, complicated projects into smaller and more easily manageable problems.
4. My favorite computer science project would be the semester-long Operating Systems assignment where we implemented the main components of an operating system that were actually able to run and work together in an emulator (and presumably on the real hardware, but I wasn't brave enough to try that).
5. The final project in Software Engineering was the worst project since it was only assigned at the end of the semester and only one person on the team had the necessary skills to do the project. I felt as though the project had nothing to do with the class since we did not learn any of the skills required to do the project.
6. Social networking sites have changed the way that many around the world choose to communicate with their friends, family, and basically anyone they meet. The other important trend is the adoption of truly portable computer devices like the iPhone, Android, and tablets.
7. My typical pattern for coding was to spend an enormous amount of time designing the entire program out on paper and trying to identify all the problems that I might encounter so that the program would be "perfect". Needless to say, the projects were rarely finished. However, more recently I have been working in a more Agile fashion, an adoption that was helped along by my discovery of the Git version control tool. In this scheme I only look ahead to the next task at hand and make changes to the existing program as they are needed. In this way, there is always something "deliverable" and seeing things working, even in a non-optimal way, keeps me motivated and therefore increases the likelihood of the project being completed.
8. Here is my picture: