Extreme Programming CH 16-19

Chapter 16 is a big list of bullet points on how to approach extreme programming.  It highlights the point of not programming for tomorrow three times to truly drive home the point.  Chapter 17 is a very short chapter that deals with scheduling.  It reminds the reader to only schedule in hours or more and not minutes.  Chapter 18 is the only long chapter in this excerpt and it focuses on tracking the progress of the project.  The chapter has a large suite of example graphs that the developers can use to track their progress.

There isn't much analysis that can be done on these chapters.  The ideas presented were pretty clear cut and straight forward.  The bullet points were somewhat of a nice addition because they got the point across without being incredibly wordy.

Design of Future Things CH 5

Chapter five focuses on automation and augmentation.  Norman talks about how automation is generally a good thing even though it may take more work at a later point.  He argues, using his coffee maker, that while the cleaning is more laborious, due to automation, one can choose to clean the coffee maker at a more convenient time than in the morning when they had just woken up.  He discusses augmentation devices that would help augment the human intelligence.  The devices, such as the cooking helper, serve mostly to aid the user in tasks that they would have done with or without the technology.

This was definitely one of Norman's least crazy chapters.  He seemed to have a better hold on the material he was talking about in this chapter.  I liked the concept of the smart home that he mentioned but was a little confused when he said he wouldn't want to live there.  He is continuously talking about cars that will take over some of the driving for the driver, yet he wouldn't want to live in a house that might accidentally turn on the lights when you don't want it.  Doesn't really make sense to me.

Extreme Programming CH 13-15

Chapter 13 of this excerpt deals with unit tests and proper methods of writing them.  The authors give specific advice to problems such as when the programmer is dealing with an external database and when code is present that doesn't have any tests already written.  The next chapter is a raw transcript of a pair programming session between the authors and how they wrote the code and the unit test.  The final chapter in the excerpt discusses releasing changes, the process, and how to avoid or fix problems that might arise.

I like the unit testing chapter.  As I have mentioned before, I think unit testing is a great idea.  The second chapter seemed a little useless to me.  I thought it was really weird that they used Small talk and not a more popular language such as C++ that most programmers would at least be familiar with.  It was much harder to follow because of their choice in language.

Design of Future Things Ch 4

This chapter is primarily devoted to the exploration of AI and its future implications in our lives.  Norman starts the chapter out with a made up story of a man stuck in a traffic circle for 14 hours because his car wouldn't let him steer out of the circle.  He then goes on to communicate some of the possible dangers of our machines getting smarter and contemplates how smart we may want them to be.  He then explores the possibilities of using swarm behavior on cars.

The book is titled "The Design of Future Things," but after this chapter its clear to me that the book really should have been named "The Design of Future Cars as Don Norman Sees It.'  Norman's fascination with cars and their designs really takes away from the book.  All he ever talks about is cars and the design questions that needs to be answered while not giving an answer himself.  His arguments could be much stronger if he had something other than cars to talk about.

Extreme Programming Ch 10-12

The first chapter is a small two page chapter about having a short design meeting between the programmers after the user stories have been recorded.  The next chapter addresses the issues surrounding implementation.  The book argues that the team uses pair programming taking a test first implement later approach.  The book heavily insists that all programmers own all pieces of the code, therefore allowing them to make quick changes when the need arises.  The chapter also describes the importance of a consistent coding standard, due to the fact that everyone owns all pieces of the code.  The last chapter of the excerpt focuses on pair programming and the functionalities that the "driver" and "partner" bring when working together.

The one thing that I really like about XP is the test first implement later approach.  I have found that in every single one of my projects, if that approach had been taken, better code would have come out of it.  The only problem that I see with it is management's reluctance to implement it.  If a manager doesn't understand coding and he/she just sees programmers working on tests for a few days with no real product being made, he/she could easily conclude that the tests were not worth it.  Other than managements problem with it, the approach could really help.

Design of Future Things Ch 3

In the third chapter of "Design of Future Things," Norman is back at it again, complaining about cars and attempting to make them better at communicating with the driver.  He discusses a simulation that he visited where the car would communicate what the driver should be doing by moving the steering wheel towards and away from the driver.  He then discusses the idea that if things are perceived to be dangerous, then the actual danger is lower because the people operating in the environment will be more careful.  Normans idea is to simulate danger in a car to help make the car safer.  Finally Norman makes small references to something called a Cobot and the Segway.

This chapter was not very different from the last two that I read.  I have a problem with the fact that Norman continuously comes up with problems but fails to offer any realistic solutions.  He finds some of the hardest problems which would take decades to solve and doesn't even attempt to seem like he has thought of possible solutions.  Because of this the book, and especially this chapter, can come over very whiny.

Extreme Programming Installed CH 7-9

Chapter 7 starts the section talking about small releases and how to achieve them in a real life project.  Many programmers will argue that their project is all or nothing, and therefore they are unable to do small releases.  The book counters that there are always small pieces that can be released such as replacing parts in a legacy system.  Doing so gives the customer time to learn what they want.

Chapter 8 explains how the customer should define the release.  This chapter is focused on what roles the customer plays in the release planning and how they should push for smaller releases.  Chapter 9 focuses on how the stories should be written.  The customer should define the story and the programmers define the point values for the stories.

This excerpt was pretty dry and bland.  Not much new info was presented in this reading.  There was some expanding of earlier points, however, I don't feel like I really learned anything new.