Book Reading #3 Design of Future Things

Design of Future Things
Donald A. Norman
Designed and Edited by Donald A. Norman

Chapter 2: The Psychology of People and Machines

In this chapter we get to see a lot of examples and discussions on the authors beliefs on possible interactions that machines and people would have and the psychological factors present in these interactions. Examples of planes, refrigerators, and even houses who interpret what their human owners want or need are given. He begins by talking about more recent examples of machines that think such as chess playing computers. He said that these were very primitive and that probably the most relevant example today is computer games that interact with and respond to the player. He then talks about how as technology for these kinds of things slowly progresses that we will begin to see the advent of what he calls the "machine-human hybrid". Essentially he breaks the differences in machines in humans down into three parts: visceral, behavioral and reflective. He gives examples of how each of these is present in different interactions of machines and humans and how in some places one or the other fails to display one of these. He again goes back to some of the examples in chapter one such as car and driver, horse and rider and talks about how each of these interactions displays each of these but there is a system of trade offs between them. He closes the chapter by talking bout how there are some subtleties to human speech that will be very hard for computers to recognize. For example, people who have known each other for many years often tend to "think alike" and when they see something they can refer to it without having to directly name the article. There are situations when humans understand what another human is conveying but this might be very hard for a machine to interpret. He points out that currently machines do this by the advent of handshaking. In fact machines talk to each other all the time, when you connect to any site on the internet or your CAPSTONE BLOG, two machines are talking to each other and confirming that you are getting to the correct place. He points out that the design of future things is going to be based largely on these communication issues and how designers begin to understand them and work to correct them.

I think these ideas are very good and very solid but some of his ways of presenting these ideas about the psychological interactions of car and driver and horse and rider are very boring and don't make a lot of sense in the spirit of HCI. It seemed that he was hammering home his own examples more and trying to make them fit when there might have been a better way to present the information. I think the most clever part of the chapter is his stories where the machines are personified and actually assigned emotions. This is not because this is how I see machines but because with advancement of technology this is what some people actually want them to do. Another item I did like was the discussion of the machine-human hybrid. The idea that machines and humans could work in harmony and your house and computer and other devices in your life could help you stay healthy and live easier is a good idea. If I had a fridge that could help me track my calorie count by talking to it I would buy one in a heartbeat and then I'd ask it to recommend something for dinner based on my calorie count for the day. These kinds of things would be useful though he does say ideas such as what if you want to make Easter eggs and cannot have eggs this week etc. The end of the chapter when he talked about handshaking and communication of devices was almost like a review of UNIX. It wasn't that he was wrong it was just dry for me due to my experiences in my UNIX class. I am curious to read on in the book and I am hoping for more specific examples and research that people have done and products they've made.

Book Reading #4 Extreme Programming Installed

Extreme Programming Installed
Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley

Chapters 4-6:

Chapters four, five and six covered user stories, acceptance tests, and story estimation respectively. These principals covered were more ideas of how each of the steps in the design process should go. In four we looked at user stories and how the team should handle them. There was a large emphasis on the number of stories that each team should have and how to properly write them on index cards and then tear up ones that you do not want anymore. There was also a large emphasis on making sure each card is short and only contains one idea, if at any time a programmer is unsure of how long an idea will take to put into action it is probably too long and needs to be split into two stories. This also led into how the programmers should be comfortable with ripping up index cards as many were going to be used in the entire process. The next chapter was very brief but did talk about acceptance testing. This is basically the idea that the customer is allowed to see the program in working order at many different times throughout the process. The programmers should have a working version of the program each week for the customer to see and be able to talk about what they finished in the last week as well as what they are going to do this week. It was also pointed out that this step in the process is important so the user is able to change what the programmers did if s/he so chooses. Lastly the process of story estimation was covered, whereby the programmers rate with a number how many weeks they think it will take. Typical ranges covered were .5 - 4 and if anything was going to take longer than 3-4 it was discussed that it should, again, be broken into two stories instead of one. The latter half of the chapter then gave examples of some user stories and time estimates.

Again, for me, a lot of this was a review of Agile as we learned in class. Some of these ideas are very solid and I do like they way that they are done. I think the most interesting part of this is the way that they do user stories and estimations as it is much easier to teach than the way that it was presented to us. I like that each programmer gets their own stack of cards and that bad ideas are literally thrown out and that stories that are too long are literally broken into two different stories. I also like the way they decide length of projects and how there is a grounded system for assigning points. The way we did it we assigned arbitrary values to each story letting the SCRUM master know how long we think the story would take then we discussed ideas. In the way that was presented in the book they had a grounding for how long to make each story (one, two three, or half a week) and they were able to draw upon past experiences to compare stories and determine how much time a programmer was going to need. The chapter on acceptance testing was almost too short. While it did hit some good points about how the acceptance tests enable the user to make good decisions and change ideas it didn't cover much more and left me wanting to know a little bit more about them. 

Book Reading #4 Extreme Programming Installed

 
Chapters 4-6:


Chapters four, five and six covered user stories, acceptance tests, and story estimation respectively. These principals covered were more ideas of how each of the steps in the design process should go. In four we looked at user stories and how the team should handle them. There was a large emphasis on the number of stories that each team should have and how to properly write them on index cards and then tear up ones that you do not want anymore. There was also a large emphasis on making sure each card is short and only contains one idea, if at any time a programmer is unsure of how long an idea will take to put into action it is probably too long and needs to be split into two stories. This also led into how the programmers should be comfortable with ripping up index cards as many were going to be used in the entire process. The next chapter was very brief but did talk about acceptance testing. This is basically the idea that the customer is allowed to see the program in working order at many different times throughout the process. The programmers should have a working version of the program each week for the customer to see and be able to talk about what they finished in the last week as well as what they are going to do this week. It was also pointed out that this step in the process is important so the user is able to change what the programmers did if s/he so chooses. Lastly the process of story estimation was covered, whereby the programmers rate with a number how many weeks they think it will take. Typical ranges covered were .5 - 4 and if anything was going to take longer than 3-4 it was discussed that it should, again, be broken into two stories instead of one. The latter half of the chapter then gave examples of some user stories and time estimates.


Again, for me, a lot of this was a review of Agile as we learned in class. Some of these ideas are very solid and I do like they way that they are done. I think the most interesting part of this is the way that they do user stories and estimations as it is much easier to teach than the way that it was presented to us. I like that each programmer gets their own stack of cards and that bad ideas are literally thrown out and that stories that are too long are literally broken into two different stories. I also like the way they decide length of projects and how there is a grounded system for assigning points. The way we did it we assigned arbitrary values to each story letting the SCRUM master know how long we think the story would take then we discussed ideas. In the way that was presented in the book they had a grounding for how long to make each story (one, two three, or half a week) and they were able to draw upon past experiences to compare stories and determine how much time a programmer was going to need. The chapter on acceptance testing was almost too short. While it did hit some good points about how the acceptance tests enable the user to make good decisions and change ideas it didn't cover much more and left me wanting to know a little bit more about them. 

Book Reading #2 Extreme Programming Installed

Extreme Programming Installed
Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley

Chapters 1-3:

The introductory chapters introduce us to the philosophy of extreme programming. It is broken down into three parts and each covers a different aspect they are: Customers, Programmers and Managers. Some responsibilities and attributes of being each are given and they are similar to the practices used in Agile. The authors then list the ideals of extreme programming and gives some insight to what each means in the sense of building a program. These are ideas such as how managers have the right to have a plan, change the plan, and get the most value out of every programming week. Programmer right s are ideas such as: the right to produce quality work, the right to ask for help, and the right to accept your responsibility and not have them assigned to you. The book then goes on to talk about the programming life cycle and how the relationship between the customer and the programmer works. Here we learn that while the customer wants results they need to be a part of the system to make sure they receive good, quality work and not try to set the programmer to strict deadlines and set high demands which will likely only get them poor work riddled with bugs. Finally the authors discus the importance of the role of the customer and how the customer should be there in each stage of development. They discuss ideas of how the customer is allowed to see and change each program iteration and needs to be there to answer questions in a clear and concise manner. The authors end with stories of how not having a customer present for even one simple question may slow development by nearly a week.

These chapters were not much new information for me, in many classes we have done agile and the system of extreme programming is very similar to this. Each of the roles of each person are very well defined and the authors provide good examples of when each of these is a factor and needs to be considered. I think the most interesting things were how the philosophies of this were much different than Agile, but I still got the same sense that the practices were intended to have the same overall effect. I have also talked to many companies about their view on Agile and they said some of the practices were very hard to implement and that they were only able to do so many of them. This makes me wonder if XP will be the same way and will be a good idea but not fully implementable by companies. I think however the one thing that XP does well that Agile does not cover is the importance of the customer in the entire process. It does seem like exchange of information and ideas would be much faster and easier with a customer present and they seem to be an important part of the development process.

Book Reading #1 Design of Future Things

Design of Future Things
Donald A. Norman
Designed and Edited by Donald A. Norman

Chapter 1: Cautious Cars and Cantankerous Kitchens: How Machines Take Control

The author talks about various technological advances and the new kinds of machines that are being invented to help our lives. He talks about ideas such as cars that help to correct steering, rooms that wake you up and greet you in the morning, kitchens that regulate and watch what you eat and various other computer based appliances. However he does not just present the good points, he also talks about their downfalls and how they are not intelligent siting friends and co workers whom he has discussed these ideas with. His main example to show this is a car navigation system. He argues that the car can only give advice and there is no communication with it. He leads this into a discussion of the idea of a symbiotic relationship with machines. He gives this arguments in terms of four examples: people and traditional tools, horse and rider, car and driver, and machine recommendation systems. His main argument is not that these do not work it is that because there is a lack of communication between the two there is only so much that the non-human can understand. In essence, because machines lack true intelligence it will be very hard to determine what all interactions that people will have with them and this can pose many problems in design of future, similar technologies. He ends by discussing other machines and how they are designed. His focus is that while it is easy to program logic into a machine to make it do a task it is much harder to see all of the possible uses and consequences of peoples actions. The main idea is the idea of a programed house, while it would be nice for the house to be able to sense stress and help calm you, what if you need to get up in the middle of the night and it greets you good morning? He claims that the difficulty is not the logic, but tying emotion to different decisions and having the machine sense what we want them to do.



I think this chapter despite going over some of the same arguments twice does being forward some very interesting issues. The main one that I liked was the idea that design and actual implementation/use are very different from one another. I have found that in many new creations that the way or purpose that people use them for is not the same as the original creators image. In fact this does not have to be seen as a bad thing, it can be seen as a good thing. The way that I see this is that (essentially) people are beta testing my product by exploring its capabilities and then commenting on how the design fails or succeeds. In fact, when a new product is developed, the best thing one could do is first give it to a very select group that will use the item constantly and then have them give feedback and comments on what people say about it. Something like the self-following luggage (mentioned in the chapter) is a good example of this as people would see it and then ask where they got it and other inquiries. If a conversation were to get started about it there could be very good questions raised "How do you know if the luggage gets stuck? How do you know if someone has grabbed it or knocked it over?" These could be taken into consideration and then reversely used as selling points for the product (Hey, we beta tested this and this is what happens if someone tries to take it *alarm*). The creation of any new product or new idea needs to have some study go into it the problem is when companies try to compete with one another and push out products without acceptable levels of testing and life-threatening consequences arise. In fact again I will agree with the author that new technologies need to be designed based on how the user is going to use them naturally and not how the company WANTS the user to act.

Intro Blog Post

Hi I am Derek Landini. After Graduation I will be working at Halliburton in Houston doing program development and testing for in-house technologies. My main interests in computing are HCI, JAVA, C# and GUI programming. My biggest strength is definitely doing graphics. My favorite project was building the AI car in programming studio and my least was doing the C++ database in the same class because of the size of the project. The best tech development is by far carbon nanotubes and anything built from them. The coding style I have come to like is agile, but I do not think that there needs to be a rigorous following of it.