Extreme programming installed Ch. 1-3

Extreme programming installed
Ron Jefferies, Ann Andreson, Chet Hendrickson
 Editors: ?

Summary:

The first chapter mainly focused on the roles and interactions of the key people in the extreme programming method: the programmers, customer, and manager. A customer should work to define the business value of the software that they want to be produced by writing stories, written examples that define an example usage of some aspect of the software. Programmers then interpret these stories to build software that behaves in a way that matches the stories of the customer. Customers can also define acceptance tests to determine whether or not the software behaves the way that they believe that it should. The main goal of a manager is to remove obstacles from the path of the programmers. Managers should plan meetings, resolve conflicts, encourage communication, and provide the programmers with all the tools that they require to build software effectively and efficiently.


Chapter 2 discusses the development cycle that takes place between customers and programmers. Customers provide stories or feature requests in order to define the value of the software and programmers in return build the defined values into the system and present it to the customer. From there, the customer can provide feedback to the programmers and further define the value of the software.

Chapter3 discusses the importance of an on site customer. Having an on site customer is critical because it allows immediate and effective communication between the programmers and the customer. It allows constant feedback on the direction that the software is heading in and allows for the customer to make sure that the software is behaving the way that they believe that it should be. Having an on site customer can help prevent  making assumptions when writing code and can help prevent road blocks that occur when the programmers are waiting on an answer from the customer before they can continue developing.


Discussion:

This reading was significant because it explained many aspects of extreme programming that may seem strange to software developers. Ideas like having an on site customer or pair programming can really improve communication when developing software and can help remove the incorrect interpretation of the customer's requirements.

The only "fault" that I could find with the reading is that the author did not go into depth about many of the concepts that he mentioned, such as pair programming and acceptance tests. However, these topics are most likely discussed in greater depth later in the book.

This book could be extended to improve upon some of the shortcomings of extreme programming. Such as the problem of having software that is more feature and code driven rather than design driven. Continually refactoring and providing a working product is great until a design problem comes up that could have been avoided by coming up with an overall design for all features before coding began.

Design of Future Things Ch. 1

Design of future things by Donald Norman.

Summary:

The first chapter focused on the need for computer human interaction to change as technology becomes more and more sophisticated. The author believes that active communication or dialogue between computers and machines is the key to designing systems that will assist humans rather than become a hindrance to them. Another key aspect of designing future devices that was discussed was the need for a more natural interaction between humans and machines. According to the author, machines should be designed around how people behave.
That is, machines should serve to assist humans without becoming intrusive or invasive. In order for humans and machines to communicate naturally they need to be able to relate to one another and leverage each ones strengths.


Discussion:

This paper is interesting because it takes a critical view on the design of many of todays systems. Many of the points that the author raises about the behavior of automated systems in cars show how unintelligent most modern systems really are.
While the author makes several valid points that should be taken into consideration when designing a system, he offers no way of implementing the smart systems that he proposes. All he offers is the fact that several research laboratories are working on similar systems right now. Many of the designs that he sees as necessary are impossible with current technology.
Possible future work relating to this chapter would be the implementation of systems that are able to better communicate to the user. A more attainable goal would be systems that are able to react to unforeseen situations. Inference machines could be used to help achieve these goals, however there are always going to be situations that machines can not react to. If there is an unknown input that the machine does not know how to process then the machine would not be able to make a logical decision.

Introduction

My name is Warren Kiser. After graduating I will start working for FactSet Research Systems in Norwalk, CT. My computing interests include software engineering, software design, computer graphics, and user interface design. Recently my greatest computing strength has been Java and all of its related tools. My favorite computer science project was the human body animation project from computer graphics. My least favorite was the wumpus world project from A.I. I see the most important tech development in the last 5 years to be Android, because it allowed for the rapid advancement of smartphones. My only pet peeve in regards to coding style is when people dont put a line break between a function definition and the open brace.