The Design of Future Things - Ch 2

The Design of Future Things

Donald A. Norman

Summary

Chapter2 is about The Psychology of People & Machines. It starts by explaining how the new kinds of intelligent machines create their own assessments and make their own decisions. However, everyday people generally have problems interacting with these machines, as they don’t understand the logic behind it. Designers seem to believe that many of these devices are so intelligent that no learning is required, the book calls this “automagical”, referring to automatic plus magical. However, we all know that machines are not perfect or completely reliable; for this reason, regular people would like to understand the decisions and reactions of machines in order to accept them better.

It is obvious that machines hardware is very different from human beings. However, the book explains how both machines and humans must function effectively, reliably, and safely in the real world, so the world imposes the same demands and requirement upon all creatures. This is why it later explains how the future of everyday things lies in products that know where they are located and who their owners are and that can communicate with other products and the environment. Today, systems are responsive, but not intelligent. They often fail, mainly because they don’t have a good sensorimotor system, but also because they usually measure different things from people, and have different goals. The chapter finishes by explaining that the fundamental restriction on people’s successful interactions with machines is the lack of common ground between them.

Discussion

I think is really interesting how the book describes the fundamental restriction as being the lack of common ground between machines and us. I have never really though about it that way. I still look at most machines as some sort of dumb objects that make lots of mistakes and make me angry. As the book explains, they are definitely useful but not really intelligent. However, if we could have a common ground with them, as other machines do with themselves, we could reach a different sort of understanding, one that can lead to intelligent interaction with a machine. I would love to know in what actionable way are people trying to do this. Everything the book says makes total sense to me, but are we actually moving towards that direction?

Extreme Programming Installed Ch 4-6

User Stories

Extreme Programming Installed

Ron Jeffries, Ann Anderson, and Chet Hendrickson

Summary

Chapter 4 discusses User Stories. In XP the system is specified entirely through stories. In order to do this, we need to find out what the customer wants, and this is done through informal analysis, or in order words: we just ask the costumer and write it in blank cards (stories.) The book explains this process, and emphasizes how important it is to get comfortable with the cards, we should not be afraid of tearing them apart and writing better stories. At the end, the chapter gives a bunch of sample stories.

Chapter 5 is about Acceptance Tests. The book makes clear that we should always test before we ship, and ideally, we should test right after we program something. There is no more important feedback than early information on how well the program works. Test everything you want working in your program, and do it in an automated way. The chapter finishes by giving a few examples on different scenarios and how you could test them.

Chapter 6 is about Story Estimation. Not all stories are the same size so it is hard to estimate the pace of the project just by looking at how many we have. However, there are several things you can do. For example, you can estimate by comparing stories; often one story is just an elaboration of another one. We can achieve this by ranking stories with a point system, and then just assigning similar points to similar stories. At the beginning, however, there is no comparison to be made so the book explains how we could start assigning points based on the “perfect engineering weeks”. Those weeks where you program perfectly all day every day are a perfect engineering week. For example, if you feel you can do a story in one perfect week, then you would give it one point, and so on. An issue with this approach is when you haven’t done anything like the story you are trying to rank. The book explains how in this case you should do some experimenting in order to find out how much time that type of work could take you. Finally, the chapter ends by giving examples of these types of experimentations, called spike solutions.

Discussion

These three chapters were really informative and actually clarified several doubts I had from reading the previous chapters. The process of user stories makes a lot of sense and seems it could be extremely effective. I have never used this process and look forward to do so in the future. The book clearly explains pretty much every detail about it so I don’t think there are any faults in this work, at least from the perspective of someone that has never used XP programming.

The Design of Future Things - Ch 1

The Design of Future Things

Donald A. Norman

Summary

The book discusses smart technology and the interaction between human beings and machines. The first chapter starts by explaining how there is no real communication between machines and us, essentially because they can’t really understand our needs to the fullest. The problem is that technology is becoming more and more powerful, and non-meaningful collaboration between humans and machines could lead to serious problems. In today’s world, intelligent technology is really limited and incomparable to human decisions. However, it is easy to blame a person for a machine’s bad decision: “he should have done this” “she should have known that”, etc. However, we must start designing for the way people actually behave, and not the way we would like them to behave. Intelligent machines should be easy to use and understand, and they should be tailored to the way humans interact and move about society. When using a machine the interaction should be natural and obvious. We need a partnership with intelligent machines, not a one-way relationship in which someone (or something) is always in control. The chapter ended by explaining that we face many problems with technology that cannot be overcome easily. “We need augmentation, not automation”

Discussion

I read “The Design of Everyday Things”, a book by the same author, about a year ago and I literally couldn’t stop thinking about design for a long time. This book has a different focus but is similar in many aspects and as interesting. Everything, from doors to cars that can drive themselves, should be design to be obvious. Humans tend to get very frustrated with machines, basically because they are hard to figure out and their decisions are sometimes unpredictable and hard to understand. A simple example: signs that say “Pull” in a door should not exist, it should be obvious that you have to pull the door in order to open it by just looking at it and the way it is designed. The same goes for any type of technology, we shouldn’t need to take a course or have special talents to use a machine. I think the point that Mr. Norman is trying to make in the first chapter is that we must realize that as technology becomes more intelligent we also need to be more intelligent about its design. Although I have only read the first chapter of this book I am really looking forward to the next chapters.

Extreme Programming Installed Ch 1-3

Extreme Programming Installed

Ron Jeffries, Ann Anderson, and Chet Hendrickson

Summary

The book is about a software development methodology called Extreme Programming, and it particularly focuses on what makes an XP project work. The first chapter explains the concept of XP and discusses the different players in an XP project. The principle of XP can apply to any moderately sized projects that need to deliver quality software rapidly and flexibly. Let’s take a look at who is needed in the process: customers, programmers and managers. Customers express what must be done in terms of stories. Programmers build the system and keep it integrated at all times so there is always a good version to look at. Finally, managers’ cause, coordinate, report, reward, and remove obstacles for the team.  The first chapter goes into more detail about the responsibilities and rights of these three players. Chapter two discusses the circle of life: define, estimate, choose, and build. It boils down to the need for the customers and programmers to understand that they depend on each other and that dependency could be responsible for the success of the project. The third chapter focuses on communication and its importance in the XP methodology. The customer and programmers need to work in concert and as physically close as possible. Written communications take much more time and effort than face-to-face conversations. However, if the customer cannot be physically present all the time it is important to get someone to represent the customer locally and be constantly in contact with the real customer.

Discussion

The information provided by the first chapters of this book was very informative and useful. I believe it discusses many things that you would think are obvious after you read them but you haven’t really thought about it before. Even for projects that might not be suited for XP, the book may be extremely useful as it has general information applicable to any software development project.

About me

1. What is your name?

Carla Villoria

2. What will you be doing after graduation?

Moving to Seattle and working for Microsoft as a Program Manager

3. List your computing interests (HCI, information retrieval, databases, etc.).

Mostly anything that could combine computer science and social justice/environment (information retrieval, software engineering, CHI, etc)

4. List your computing strengths (a language, focus area, etc.).

C++, Python, and Program Management

5. What was your favorite computer science project that you worked on and why?

All projects from the Information Retrieval class (470) as I found them all very current and relevant.

6. What was your least favorite and why? 

All projects from the Introduction to Computer Systems class (313), specially the malloc function one. What I learned through it was not worth the effort.

 

7. What do you see as the top tech. development of the last 5 years and why?

On a large scale smart phones like the iPhone, Android, and Windows Phone 7 as they have changed the way we interact with computers. On a smaller scale, the EnergyHub Dashboard because it aims at making us (and the world) save energy. Also, twitter, as it has revolutionized social media and the way we stay informed.

8. Provide some insight into your management/coding styles. This could include your preferred coding method, how you use line breaks, what time of day you work best, or any other relevant programming-related facts.

I am not really picky about programming styles, and can adjust to anything.