The Design of Future Things - Ch 6

Summary

Natural Mapping

The chapter discusses communication between machines and people. Good communication requires both sides to understand why things are happening or why not. The problem with machines is that the creators often assume that if the machine works perfectly, then they don’t need to provide people with the information behind its actions. However, in order to have real communication with machines we need their feedback. The problem is that today many devices provide minimal feedback, and it is usually more annoying than informative. So how to provide better feedback? With natural interaction: interaction that doesn’t need explanation. The chapter ends by explaining how the lack of common ground between people and machines is a fundamental problem. However, this is not something that cannot be fix by new design. Successful future design will depend on how well the machine can communicate with its user: in a continuous, unobtrusive, and effective way.

Discussion

I really liked this chapter as it tackles a critical and obvious problem: machine communication. I think the chapter nails down why we need natural interaction between machines and humans. It gives really clear and easy to understand examples. However, as always, is more about this utopian futuristic view than about the concrete steps we need to take towards the goal.  

Extreme Programming Installed Ch 16-18

Summary

Chapter 16 – This chapter is a summary of recommendations to achieve the XP goal of delivering well designed, well crafted, flexible structured, properly documented, and tested computer programs. Here are a few of the many recommendations: don’t try to design the whole system before you start implementing it, don’t try to freeze requirements before you start implementing, don’t produce documents or other artifacts that aren’t being used, don’t separate the team into designers and coders, and don’t build for tomorrow.

Chapter 17 – This chapter is about stories time estimation. A few things to remember are the following: estimate each task that you sign up for, estimate the amount of actual time you will spend working, and pay attention to the actual time you spend working. After a few times of doing this, you will be able to accurately estimate the amount of time tasks will take you.

Chapter 18 – This chapter discusses tracking and reporting approaches. There are 4 major things that need to be tracked and reported: resources, scope, quality, and time. Keep track of key resources, number of developers, testers, etc. Also, keep a close eye on the number of stories over time, how many exist, how many are done, and how many more are expected. Use a standard acceptance-testing graph showing number of tests and number succeeding over time. Finally, track the results of each release plan so you are aware of your time constrains. The chapter goes into more detail of each of these tracking mechanisms.

Discussion

As always, the chapters are short, sweet, and easy to understand. Chapters 16 and 17 were mostly about recapping what has already been said before. Chapter 18 was interesting; however, I feel the book is starting to repeat itself too much. I understand they just want to reiterate in order for the info to really stick with us, but I am getting a little tired of it.

The Design of Future Things - Ch 5

Summary

Automation often satisfactorily performs its tasks but adds an increased need for maintenance. For example, with an automatic coffee maker, we trade a little bit of work at an inconvenient time, with the same or more work at a convenient time. Everything in our society is becoming more and more automated. However, if a system is automated it is not necessarily intelligent, but what the book calls adaptive, because it can continually adapt its behavior to the environment. In any case, automation can be annoying, and even dangerous when intrusive. The chapter gives a couple of examples of non-intrusive systems that fit smoothly into people’s life styles. Finally, the chapter discusses autonomous design versus augmentative design. Autonomous devices can be useful when jobs are dull, dangerous, or dirty. However, people have any unique capabilities that cannot be replicated in machines, and for this reason augmentative technology has proven to make more sense in most cases. 

Discussion

It was easy to relate to this specific chapter, as it is a more realistic one. In general, I really like the book, but sometimes the ideas are too futuristic and not very concrete. This chapter, however, talks about the difficulties of automation nowadays and how we should design devices not to overwrite what we do and add stress, but to complement our skills and make our lives easier. I believe that is the real challenge; cooperation needs to exist between machines and humans. I don’t really want a machine to make decisions for me; but I would like one that would somehow help me make those decisions.

 

Extreme Programming Installed Ch 13-15

Summary

Chapter 13 - Unit Tests – This chapter is about the importance of having automated tests for everything. The best way to write tests is to do it at the beginning – test a little, code a little. After you have design a test that encompasses the entirety of the code you are testing you can release the tests and the code. As the code, the tests will become a permanent part of the system and they need to run at 100 percent all the time. This will ensure an easy incorporation of new code into the system by facilitating the catching of errors promptly. The chapter ends by summarizing the testing steps and answering some testing questions.

Chapter 14 – Test First, by Intention – In this chapter they go through an example in order to illustrate two main points. First, we should write new code only when we have a test that doesn’t work (test-first programming). Second, we should not think about how to do a thing, we should think about what we have to do (programming by intention.)

Chapter 15 – Releasing Changes – This chapter explains the process of releasing code to other programmers in your team. There is essentially three phases for the code in an XP project. First, the local phase, where you and your partner just started working. Second, the release candidate phase, where you have finished your task and are ready to release it. Third, the release to the repository phase, were the code is submitted and is guaranteed to work.  There are two common problems with releasing changes: slow mergers and lost changes. In order to avoid these problems, try to release your changes more frequently, and always back up your source code. 

Discussion 

As with a lot of other chapter in this book I think the material makes a lot of sense but is probably very hard to implement. Having tests for everything is an ideal goal, but a hard one to achieve, especially in a large project. I try to relate everything in this book to our specific senior design project and I have problems doing it especially because our team is super small (just a pair.) However, in general the chapters make a lot of sense and are simple to follow and understand.

The Design of Future Things - Ch 4

Summary

This chapter discusses automation and how we have or could become servants of our machines in the future. For example, he talks about cars and how they have become “computers on wheels.” For now, some of the automation is total, while other parts are sort of controllable for the user. However, he argues that cars will soon start communicating with other cars, exchanging all sorts of interesting information, and becoming more and more automated. According to Dr. Norman, technology will never solve all the problems of humankind, but neither will it enslave us. However, automation can lead to people relaying too much on machines that can easily make mistakes. He gives the example of airplane pilots falling asleep because airplanes are too automated. Although generally it is not extremely dangerous for airplane pilots to fall asleep, it is for car drivers. If indeed cars were completely automated, he argues that it would be safer, but the real problem is the partial automation process, were different cars would have distinct capabilities and automation mechanism and it could lead to confusion and accidents. 

 



Discussion

I enjoyed the chapter, especially because although he paints this remote image of the future he is also very honest about our capabilities as of today. For example, he clearly states that it takes a long time for ideas to become concrete tools. Also, he indicates that changes like the ones he is talking about will not just pop out of nowhere. There will be plenty of warning. Moreover, just by taking a look at the conferences worldview you could accurately predict what is the next big idea. I think most of his general ideas of a futuristic community are really distant. However, as we have been experiencing in the past, small increments will happen rapidly and be widely accepted by society.

Extreme Programming Installed Ch 10-12

Summary 

Chapter 10 – Quick Design Session – The chapter essentially discusses design sessions and for who and why are they useful. After breaking down a story into tasks you might find yourself stuck. If so, get a few people together and spend no more than half an hour designing the solution for the task. After listening to your colleague’s ideas, pick the simple one and start coding.

Chapter 11 – Programming – The chapter talks about several key points for XP programmers. First, all programmers must own all the code, so there are no delays in fixing or making the code better. Second, the code must be as simple as possible. Third, keep refactoring, which is the process of improving the code’s structure while preserving its function. Fourth, integrate code as often as possible. Fifth, use a coding standard. Finally, do not work more than 40 hours per week.

Chapter 12 – Pair Programming – In XP, all code is written by working in pairs. Pair programming means two programmers, side by side, working together to write the program. Both partners have responsibilities during the process and its not just one programmer looking at another one code. They both have to be very involved. If done correctly, pair programming will make you go faster in any situation.

 
Discussion

As with the rest of the chapters I have read, I believe the book is very well written and really easy to follow. However, I think most of the points they made in this three chapters are easy to write and agree on but actually hard to accomplish. For example, integrating code too often and early can sometimes be very difficult, time consuming, and in some occasions pointless. Also, I believe working in pair, side by side in a productive manner, is incredibly hard to achieve. First, it is hard for the driver as sometimes you can’t concentrate with somebody looking over your shoulder. Second, it is also hard for the partner as it is very easy to get lost on somebody elses code. Overall, if all these requirements were followed I don’t doubt it would be a much practical and productive way of programming.

The Design of Future Things - Ch 3

The Design of Future Things

Donald A. Norman
Summary

Chapter three discusses Natural Interaction with machines. Mr. Norman starts by comparing how we relate to machines that beep, like an alarm, the dishwasher, the microwave, etc to the way we react and interact with natural sounds, environmental sounds. It is obviously very different; so why do we design our devices to transmit unnatural sounds? Well, it is the easiest ways for designers to add signals to machines, but sadly, it is also the least natural way of doing it. In the future we should use natural signals, like the sound of boiling water in a kettle, which has no fancy electronics and is naturally produced by the water boiling. This should be the model for other systems. The chapter then goes on to explain how important implicit communication is for intelligent design because it informs without interruption and annoyance. However, designs have become intentionally more silent as the sounds usually used are annoying. These noises, however, could be pleasant if well design. In any case, sight and touch provide alternative modalities as well. The chapter later discusses affordances and how important they are in the design of future things. Also, it talks about how machines should not infer the motives of people or try to second-guess their actions, as this could be unsettling and dangerous. The chapter later talks about risk and how studies have found that when an activity is made safer the accident rate does not change. This means that we tend to somehow keep the risk the same, so if an activity seems safer we will act less carefully when doing it.  We could reverse this and say that the more dangerous something appears to be, the more care the person will exert, so why not make activities look more dangerous in order to make it safer? This sounds a little vague but the chapter actually goes ahead and explains several examples of how we could do this. Finally, Mr. Norman gives several examples of natural interaction devices, including the Segway and Cobots.

Discussion

I find it really interesting how a lot of people in our class are complaining about this book and stating that they believe the author is crazy. In my opinion, everything he says makes a lot of sense. I understand that his ideas might be hard to imagine in today’s world; but if we could actually have a natural interaction with machines I think humanity would be much more productive and happy. I don’t think all of a sudden we are going to get overloaded with these types of machines, but I do believe that gradually we will be using more and more devices in a natural and obvious way; and that is pretty much what he is saying. Hopefully, even devices that already exist and we are accustom to will eventually be reinvented to make our life’s easier and safer.

 

 

Extreme Programming Installed Ch 7-9

Extreme Programming Installed

Ron Jeffries, Ann Anderson, and Chet Hendrickson 

Summary

Small Releases – Chapter 7 talks about releasing workable software little by little, instead of just as a whole at the end. It is very common in projects to change directions. Because of this, releasing early and often could make this change process more dynamic and natural. By doing this, you are also providing the customer with an actual tool that they can evaluate and give you feedback on. However, sometimes it is hard to determine how to this. In order to illustrate this the chapter ends by giving several examples on how we could design small releases in specific and concrete projects.

Customer Defines Releases – Chapter 8 discusses how the customer is involved in the process and how he/she defines the meat of the releases. At first, the customer will write stories and make sure that what he/she wants has business value. Then, the customer will hand those stories to the programmers, who will ask questions and estimate how much time and effort each story will take. Finally, the chapter discusses the release planning meeting, which as the name implies, is to plan the smooth execution of the project, to estimate how much time (in points) will each story take, and how many points per interaction will the team be able to achieve.

Iteration planning meeting outcome

Iteration planning – Chapter 9 is all about planning short iterations with clear objectives. In order for the customer to prepare for the interaction planning meeting he/she should choose the most important stories which points sum to the total of maximum points that the team can manage per week (determined in the release planning meeting). Then, the customer will explain the stories and the programmers will brainstorm engineering tasks, and divide and estimate the work. Finally, the chapter explains a specific planning method for assigning and estimating stories. 

Discussion  

Until now, this book has been incredibly easy and interesting to read. The chapters are concise but at the same time convey a lot of information and are easy to follow. The process described in these three chapters seems very straightforward and useful. However, in my previous experiences with projects I have found small releases hard to implement, as I am usually focus on a specific final outcome. On the other hand, as the book illustrated, most projects can actually be divided into small releases and it truly seems to have a positive effect in the project and team as a whole. I look forward to applying this methodology to my project.