Extreme Programming Installed

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2000 Addison-Wesley

Chapter 13

Summary:

While coding, it is important to test code in bits and pieces as it is written instead of doing a big test at the end of the project.  Unit testing involves checking to see if input yields the expected output.

Discussion:

Unit testing certainly saves time in the long run, but it is always tempting to forgo intensive testing while coding.  Still, the testing a little bit at a time is far mor efficient than testing a huge block later.



Chapter 14

Summary:

When writing unit tests, it is best to start with little tests.  In addition, the intent behind code should be clear, as opposed to simply having an algorithm.

Discussion:

 Mostly just providing examples of concepts from the previous chapter.



Chapter 15

Summary:

 When working on a team, code management is very important.  A repository is a common structure used to manage code, but team members need to be careful that they don't mess up the code in the repository.

Discussion:

I've used SubVersion on several occasions, and it is certainly an overall boon to a team.  Everyone must know what they are doing though, or else they might commit erroneous changes to the repository and cause major headaches down the line.



The Design of Future Things

Reference:
The Design of Future Things
Donald A. Norman
2007 Basic Books

Summary:
Norman coveres the differences between intelligent autonomy and intelligent augmentation.  The former concerns systems that try to guess the intentions of people, and the latter provides tools that can be used at the discression of people.  Autonomy should ideally be reserved for dull or dangerous tasks, while augmentative tools leave more power in the hands of the user.

Discussion:
Norman basically just expands on things he talked about earlier in the book.  Autonomy is indeed useful, but when taken for granted can lead to distrust or tragedy.  Augmentation, on the other hand, is optional, so the user has more freedom in deciding the application of a device.

The Design of Future Things: Chapter 4

Reference:
The Design of Future Things
Donald A. Norman
2007 Basic Books

Summary:
As technology advances, people become more and more dependent on technology.  As the title states, we are becomming servants of out machines.  Before too long, we will likely have cars that drive themselves, systems that decide how to entertain the user, and kitchens that cook for us.  One of the problems that results stems from when machines fail in an automated task, causing the user to suddenly make a decision on what should be done.  However, when the machines perform properly, it can greatly increase our quality of life.

Discussion:
I found the description of a traffic "swarm" interesting, as I did some research into a similar AI topic not too long ago.  I used intersections as a point of reference, and tried to determine how cars could cross paths without ever having to stop.  My eventual conclusion was very similar to what Norman describes, though my description was on a lesser scale.  Though we may be more dependent on technology than in days past, that doesn't necissarily make it a bad thing.

Extreme Programming Installed

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2001 Addison-Wesley

Chapter 10

Summary:Once the tasks for a given story have been decided, a short design session should be held.  This session should act to eliminate any doubts on what needs to be accomplished for the stories.

Discussion:
Makes sense.  A short design session will help to clarify what a task entails.

Chapter 11

Summary:
Since a programming team shares all of the code they write, it is important to have a coding standard that the team follows.  This way there will be less time spent trying to figure out what another member was doing, and more time actually spent coding.  In addition, all the programmers share ownership of the code, so one person can make any needed changes to anothers code.

Discussion:
 I have been in situations before where I needed someone elses code to have some functionality that wasn't there, but I didn't feel comfortable in altering their code without asking them first.  The concept of collective ownership eliminates this problem, so I can see myself making use of it in the future.

Chapter 12

Summary:
Two programmers working together on a common project not only generate more code, but better code. In the end, both programmers have a working knowledge of the subject, instead of each one knowing half of the subject.  Pair Programming is accomplished through having a driver and a partner.  The driver types the code, and the partner actively engages in the development.  The two can switch roles at any point.

Discussion:
 This is something that is new to me.  It sounds like it would be awkward at first, but given enough time I believe I could get used to it.

Extreme Programming Installed: Ch. 7-9

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2001 Addison-Wesley

Chapter 7

Summary:

It is ideal to release small portions of a system under development so that the customer sees real value and gets tangible functionality during the development process.  Some applications can't be released incrementally, but workarounds can be found by interfacing a new system with the old one.  Almost every large system can be divided into subsystems, and by releasing these as able to the customer, the customer gets the best value for their money.

Discussion:

Another key part of the extreme programming I've experienced.  This ties into the user story aspect, in that each story was a piece of functionality, and each story was able to be used upon completion.



Chapter 8

Summary:

 As a customer, one should expect multiple releases for a system.  Each release will have multiple iterations, and during each iteration multiple user stories will be completed.  As a customer, then, one should prepare the user stories, help the programmers estimate the difficulty of each story, and answer any questions they have.  If something isn't going the way you anticipated it, then the issue can easily be brought up at the start of the next sprint.

Discussion:

 Based on my experiences, this still sounds like textbook Extreme Programming.  If nothing else, XP encourages communication between the customer and the programmers.



Chapter 9

Summary:

 Several things have to happen during iteration planning.  A meeting takes place, where the customer presents the user stories to the programmers.  The programmers assist into breaking the stories down into tasks, and determine which of these tasks are necissary to implement the story.  The estimation phase follows, where a programmer sign up for the work they believe they can complete, and they estimate the difficulty of the work.

Discussion:

One of the great things about XP is that people typically get to work on what they wish to work on.  The sign up/estimation phase decreases the chance that someone will have to work on something they don't want to, and increases the chance they will work on something they enjoy.



The Design of Future Things: Ch. 3

Reference:
The Design of Future Things
Donald A. Norman
2007 Basic Books

Summary:
Though most electronic devices have feedback in the form of flashing lights or buzzers, the information they provide is not always helpful.  At the same time, many devices that employ useful noises become more and more silent.  Norman believes that affordances, or the range of activities that can be performed upon an object, should be integral in designing new things.  In addition, devices should not try to predict the actions of people, but should themselves act in a predictable fashion.  Norman also notes that an effective method of improving safety is to create a sense of danger without actually increasing the danger.  This trick leads people to behave more cautiously than they normally would. 

Discussion:
I am particularly fond of Norman's description of cobots, or robots that collaborate with users.  For example, if a user pushes on the arm of a factory robot, the arm will augment and follow the force from the push.  This leaves people in control of the action, and provides a predictable pattern that the machine follows.  Granted, I'm enthralled with the possibility of the robotic exo-skeleton, but I recognize the more practical uses of cobot technology.

Extreme Programming Installed: Ch 4-6

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2001 Addison-Wesley

Chapter 4

Summary:

User stories are used to convey what a system needs to be able to do.  They highlight how the customer wants the system to function.  Ideally, stories are written by the customer.  More stories are required with larger and more complex systems, and if a story gets too big it may be broken down into smaller stories.  If needed, new stories may be added/substituted at the beginning of an iteration.

Discussion:

As an XP veteran, I am all too familiar with user stories.  My experiences had my team (the programmers) coming up with the user stories based on the user's specifications, so I can attest that it is better for the customer to provide the actual stories.  Seeing the many stories associated with a large system can be daunting, but it is a good way to break down a large project.



Chapter 5

Summary:

Acceptence tests are used in conjunction with user stories to define when a story has been suitably completed, or accepted.  These tests define certain criterea that the system must be able to do before any specific story is accepted as complete.  Ideally, these tests should be automated and completed in the same iteration that the story is scheduled for.

Discussion:

The acceptence tests are a great way to gague how far a product is from completion.  Though there are times when it seems like the customer is expecting too much from any given feature, in the end these tests make the whole process run smoother. 



Chapter 6

Summary:

To streamline the development process, it is wise to estimate how difficult any given story is.  Therefore, at the beginning of each iteration, the team estimates the difficulty of the stories in that sprint.  As time progresses, estimations are made more accurate through experience and comparison to previous stories.  However, estimates are unreliable when facing a task that nobody is familiar with. 

Discussion:

 In my XP experience, I often found estimations to be useful.  However, there were occasions where they were quite misleading.  Sometimes people would estimate that difficult tasks would be simple and vice versa.  Extimations are a useful tool, but can't necissarily be relied upon.



The Design of Future Things: Chapter 2

Reference:
The Design of Future Things
Donald A. Norman
2007 Basic Books

Summary:
Currently, machines are most likely to automatically perform functions based on the data they get from their surroundings.  In the future, it might be possible for the machine to explain why it is performing a certain action.  In the meantime, there is a wide gulf between how a person interacts with the world and how a machine interacts with the world.  Humans perceive their environments with millions of cells working in unison, while a machine senses the world through powerful, though inflexible, sensors.  As a result, people and machines have little in common.  Machines that acknowledge this gap will often suggest, rather than dictate, actions.  This provides the user with a choice, and avoids the lack of common ground.

Discussion:
The more I read Normon's work, the more I like him.  At one point or another I have thought about topics that he addresses, and I've typically come to the same conclusions that he does.  Given my interest in AI, I would like to see the lack of common ground between machines and humans eliminated, because I think the best way to develop a true AI is through making it experience the world as we do.  It will certainly take time, but I think it can be done.