Book Reading #4: Design of Future Things - Ch2

The Psychology of People and Machines

Reference Information:
Title: Design of Future Things
Author: Donald Norman
Publication: Basic Books 2009.

Summary:
In this chapter, Norman explains the psychology of people towards machines. He says that machines are made up of mechanical and electrical parts, on the other hand, humans are made up of highly complex biological tissues, ligaments and muscles. The brain is capable of intense parallel computation that the machines are not. Animals and people have evolved complex systems of perception and action, emotion and cognition. Machines need analogous systems. Human brain has three stages of processing - Visceral, Behavioral an reflective.
Most exciting of future technologies are those that enter into symbiotic relationship i.e. human+machine, for example, car+driver. This splits the processing levels, the machine takes over the visceral levels while the operator takes over the behavioral level. As the technology progresses, the machine is also taking over the behavioral components. Author claims that these systems aren't really intelligent, they are just responsive. All they do is to respond to the sensor signals, as they were programmed to do. Norman argues that for effective communication and interaction between man and machine, there has to be a common ground. The lack of this common ground is a major cause of our inability to communicate with machines.

Discussion:
I've loved reading Norman's writings. The simple examples he provides to support his theories are just awesome. I find all his arguments about difficulty of communication between humans and machines to be extremely convincing, especially, the common ground argument and his argument about the composure of human body vs. a machine.

Book Reading 3: Extreme Programming Installed (CH 4-6)

Sample: User Story
Reference Information:
Title: Extreme Programming Installed
Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson
Publication: Addison-Wesley Professional; 1 edition (October 26, 2000)

Summary:

          User Stories
User story is the short description of the behavior of the system, from the point of view of the user of the system. First step is - analysis i.e. finding out what the customer wants. The user story is the medium of analysis i.e. the medium of communication between the customer and the programmer.User stories are nothing but couple of sentences written on an index card (as shown in the picture above). Sometimes, the stories get complex and the programmer may need to help the customer to write the stories. It's important that complex stories are broken down into simpler stories. How many stories are required depends upon the complexity of the final software product. Stories shown ideally encompass a week or two pf programmer's time. Once the programmer is done implementing the story, the next step is - "acceptance tests."

          Acceptance tests
Acceptance tests allow the customer to know when the system works, and tell the programmers what needs to be done. It's not a good idea to leave the testing phase to the very end, by this time, the programmers have forgotten what and how they had implemented the features. This leads to long debugging sessions and slows down the project. The code keeps on changing rapidly and the only way to move rapidly with confidence is to have a strong network of tests, both unit and acceptance, that ensure that the changes to the system don't break things that already work. The tests must be automated. Acceptance tests need to be in the same iteration in which the story is scheduled.

          Story Estimation
Customers need to know how much the stories will cost in order to choose which ones to choose and which ones to defer. During the project flow, the story time is estimated by comparison, i.e. the story being addressed is compared to a similar story that has been worked on before. If both the stories are similar in complexity and difficulty, they will take about the same time to complete. This is how programmers estimate the time it takes to finish a story. Its always a good idea to estimate in groups, this helps in reducing errors in estimation. In the beginning of the project, there are no stories to be compared to, which is why spiking is used. Spike involves writing of some sample code so that the programmer will learn enough to estimate.

Discussion:
All the tools mentioned by the author are extremely useful. I have used agile development methodology in one of my classes before and it's extremely effective. Extreme programming is a part of agile methodology, except, it's more like Agile on steroids. It aims for fast actions, rapid results and evaluation without leaving any room for errors. These tools are designed using personal experiences and I can see how they can increase efficiency, accuracy and cost effectiveness.

Book Reading 2: Extreme Programming Installed (CH 1-3)

Reference Information:
Title: Extreme Programming Installed
Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson
Publication: Addison-Wesley Professional; 1 edition (October 26, 2000)

Summary:
"Extreme Programming (XP) is a software development methodology which is a part of Agile development methodology. It is intended to improve software quality and responsiveness to changing customer requirements." The author talks about how to deal with changing requirements. This methodology keeps the system built at all times. The responsibilities are divided among customers, programmers and managers.
The author focuses on the importance of the customer being close to the programmers so that if the programmers have any questions, they can immediately approach the customer. Finally it's the customer who makes the calls. The XP process lets the team predict more accurately how much work can be done in a given time frame. Program is based on a simple, clear design which helps to produce the software quickly. Extreme programming is about careful and continuous design, rapid feedback from extensive testing and development of high quality code. Ownership of the code is shared, so the work doesn't get halted for whatever reason. This methodology makes programmers job easy and gives the customer what they need the most - business value.
The manager on the other hand, doesn't actually do things, but he causes the things to be done, coordinates their doing and reports the results. He is responsible for arranging the meetings, resolving conflicts and for ensuring productivity. The manager also gets to give the rewards.
The main advantages of this methodology is that there is extremely good communication between the client and the programmers. The programmers are given the flexibility to choose what they want to work on. The program is built and ready for deployment at all times.

Discussion:
The methodology is brilliantly designed. The designers have addressed almost all the issues that can go wrong in the software development process. Being a part of the agile methodology, XP is definitely very successful in the modern day software development industry. I have had a personal experience using the agile methodology in one of my classes and have seen how well it works. I firmly believe with the author's opinion that the customer should be on-site and very approachable so that programmer's questions and concerns can be solved immediately, without wasting any time.

Book Reading #1: Design of Future Things - Ch1

Cautious Cars and Cantankerous Kitchens: How Machines Take Control

Reference Information:
Title: Design of Future Things
Author: Donald Norman
Publication: Basic Books 2009.

Summary:
In this chapter the author talks about how machines are getting smarter, and as they are getting smarter, they are taking more and more control. Whenever a task is partially automated, it is essential that each party, human and machine, know what the other is doing and what is intended. For this, there needs to be proper communication/dialogue between the machine and the human. What we see today is one way communication - monologues. And two monologues do not make a dialogue.
As technology becomes more powerful, its failure in terms of collaboration and communication becomes extremely critical. The author stresses on Socrates's point that a technology that gives no opportunity for discussion, explanation or debate is a poor technology. Failure in proper communication can lead to accidents. If the actions of so-called intelligent device lead to an accident, it will probably be blamed on human error.
It is important for us to understand that even though machines are superior to us in some ways like speed, power and consistency, they lack social skills, creativity and imagination. It is this mismatch that matters because this is what gives rise to frustration, anger, disappointment and sometimes, injury. Machines can work very well in controlled environments where there are no unexpected events or human interference. After all, no matter how smart machines get, they will always have only as much sense as the designers were able to program into them, which isn't really much, given that they can't really know what's going on.

Discussion:
I completely agree with what the author has to say about the smart technology and the machines taking over. I believe that the machines will never completely take over and singularity is not possible. However, our dependence on machines and machine intelligence will keep increasing. For example, with the advent of GPS navigation, people don't remember directions any more, they completely rely on the GPS navigation. So, in a situation in which the navigation systems malfunctions, the result would be extreme frustration and disappointment.
The lesson to be learnt here is that it's good to use machines to save time and for convenience, but that doesn't mean that we forget how to get the work done without the machines. Complete reliance on machine intelligence is definitely not something that we desire.

About Me

What is your name?
Jaideep Balekar

What will you be doing after graduation?
Graduate School

List your computing interests
Information storage and retrieval, HCI

List your computing strengths
OOP: Java and C++

What was your favorite computer science project that you worked on and why?
Braitenberg vehicle simulation - CSCE 452 Robotics

What was your least favorite and why?
All projects in Haskell.

What do you see as the top tech. development of the last 5 years and why?
6th Sense - MIT

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 work best at night.