Sunday, February 27, 2011

Extreme Programming Installed, Chapters 19-21

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000



Summary
Chapters 19-21 of Extreme Programming Installed focus on steering the project. The critical concept is that estimates are wrong, and extreme programming projects need a way to quickly and easily adapt to delays and problems. This is accomplished by steering the project so that changes in estimates and priorities can be made seamlessly during development. Both the customer and the programming team will learn over time to better estimate how long each type of story is likely to take. In some cases this is a good thing: many teams actually begin accelerating as the ground work is finished which makes subsequent tasks much easier. The authors believe that steering will generate a more successful project than one which tries to accomplish everything as it was originally imagined.


Steering requires some measurements that can help with the decision-making process. The most basic measurement available is the number of stories being completed per iteration. Stories should always be completed fully by the end of the iteration - it is better to have nine completed stories than ten stories 90% complete. To avoid the situations, programmers must learn from past stories so that they can more accurately predict the cost of each new story. To make this work even better, a tracker should be chosen to follow each task and to personally check with the programmer to make sure that everything is on target. If the tracker discovers a problem, these steps should be followed:

  1. Present the problem to the entire team; maybe someone can help
  2. Solve the problem within the team if possible
  3. Give the problem special attention - possibly change partners or replace the pair altogether
  4. Get the customer involved as soon as it is determined that the team cannot handle the problem
Tracking is critical to help overcome any unexpected problems and helps build team confidence that the project is moving along as planned.

Release-level steering focuses on when the release is, and what needs to be done at that time. To gauge how a release is proceeding, simply check the number of stories completed (where they pass the acceptance tests) out of the total number planned for that release. The most valuable stories should be the first added to each iteration so that the software has the highest value each and every day.

Opinion
These three chapters offered very little new material. They appear to be a re-hash of what was already discussed earlier in the book. The only remotely interesting parts were how to choose a tracker and that the customer should be told of any problems as soon as possible.


Sunday, February 20, 2011

Extreme Programming Installed, Chapters 16-18

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000



Summary
Chapters 16-18 of Extreme Programming Installed act as a guide to implementing the ideas presented in the previous chapters. The chapters covered general ideologies of extreme programming as well as offering specific measures that can be used to gauge completion.


An extreme programming produced piece of software should be well designed, well crafted, flexibly structured, properly documented, tested, and should meet known and documented requirements. To achieve this, the team should follow these guidelines:

  • Do not design the entire system before implementation since requirements are liable to change
  • Practice continuous design, refactoring where necessary
  • Requirements should not be frozen at the start of the project - let the customer change his mind
  • Take stories in any order
  • Do not produce design documents until the end when the design is actually final
  • Focus on writing clear code and communicating with the customer
  • Do not make documentation that is not being used
  • Publish progress reports frequently
  • Let team members be both a designer and a coder
  • Do not design and implement for predicted future requirements, only design for what is needed now
Estimating tasks becomes much easier as the programmers gain experience, which then makes selecting which stories to implement a much simpler and more efficient problem. The programmer simply has to estimate each task that is assigned to him in terms of implementation time, without including design time. After completing the tasks, the programmer will then have a base for comparing new tasks so as to be able to more accurately predict their cost. Each iteration the estimate should become more accurate.

A program must be constantly tracked for progress in this categories: resources, scope, quality, and time. The quantity of resources committed is simply the number of developers, computers, on-site customers, etc. The best way to measure scope is by using a bar graph where the hight of the bar represents the total number of stories and the shading on the bar shows the number of completed stories. Each completed iteration should have a bar on the graph. Quality is tracked by graphs on unit test scores (which should always be 100%) and acceptance test scores. These can be further broken down by product area. Critically, the programming should be observed carefully because any trouble to the project will show up there first. They will become less playful and more stressed if the project begins to fall behind or become overloaded.

Opinion
Chapter 16 provided a succinct summary for the entire extreme programming ideology. The most interesting part of the recommendations is that requirements should not be frozen at the beginning. I know this to be true since I have seen first-hand what freezing the requirements leads to in a large project. It actually defeats the whole purpose of agile development if any new ideas cannot be implemented because they are not part of the original specification. It leads to an unsatisfying situation where both the programmers and the customer know that the project could have turned out better but was restricted by the original fixed plan.

 Dos and Don'ts 

Monday, February 7, 2011

The Design of Future Things, Chapter 6

Reference Information
The Design of Future Things
Donald A. Norman
Basic Books, New York, 2009



Summary
Chapter 6 of The Design of Future Things emphasizes the need for effective communication between humans and their machines. The original mechanical devices that are now being replaced were fairly obvious in their working, so the operators could easily see how it accomplished its task. In addition, the physical nature of these machines gave a natural form of feedback in the sound that they make during operation, even providing information about which stage of the operation is currently being undertaken. An example of this would be the dish washer, which provides natural sound while it is in operation and the user can easily identify when the process is complete. Modern electronic devices lack these advantages, instead feedback must be explicitly devised by the designers.


The author writes that the three keys to working with intelligent systems are communication, explanation, and understanding. People can communicate with each other and animals by observing, often subconsciously, their body language. To help bridge this gap, machines should provide constant feedback to the user, even if it is working correctly. That does not mean that the machines should be blaring status updates at the user, instead it should be a subtle form of communication. Quiet is good in this case, but silence may not be. The current implementation with lights and beeps are completely artificial, therefore they are much less effective at communicating than natural means. The user must consult the manual to figure out what a particular pattern of beeps means. Feedback is useless unless it can precisely and clearly convey the message that is intended, and is important for reassurance, progress reports, learning, special circumstances, confirmation, and governing expectations.


To illustrate the communication problem further, the author gave an example from his time working at Apple. The Apple Newton was an innovative tablet that attempted to take user input in the form of writing and translate it into digital form. It did this through a complicated mathematical system that looked at whole words as a single unit. It would often give quite inexplicable results where the output was in no way related to the input from the user's point of view because the user did not understand how the device worked and blamed the device for its shortcomings. A newer system that was released looked at letters individually, so when something was mis-translated the user could easily see that the letter they wrote was not formed properly, and therefore blamed themselves instead of the device. 


Finally, the author gives his opinion on the best ways to communicate between man and machine. He says that implicit communication, natural sounds, and sensible signals are critical. Calm technology exemplifies this line of thinking because it attempts to engage both the center and the periphery of the user's attention, and can switch between them as the situation requires. Natural mapping is some form of feedback that should be there naturally but sometimes is engineered out (for comfort or convenience) and causes problems since it is critical for successful operation. The author leaves us with these design principles: provide rich, complex, and natural signals, be predictable, provide a good conceptual model, make the output understandable, provide continual awareness without annoyance, and to exploit natural mappings to make interaction understandable and effective.


Opinion
The chapter appears to be a rehash of earlier material from the book. The most interesting topic discussed was the failure of the Apple Newton. The author illustrated well how the user's inability to understand how the product worked led them to believe that it was a poor product (which it may have been) since it gave such strange results that seemingly had no relation to the input.




An Apple Newton

Saturday, February 5, 2011

Extreme Programming Installed, Chapters 13-15

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000



Summary
Chapter 13 of Extreme Programming Installed discuses the need for creating unit tests and their constant use throughout the development process. It is the programmer's responsibility to create a test for everything that could possibly break in the system so that any regression in the future will be immediately detected. To facilitate the constant testing, the unit testing system must be completely automated so when a test is added, no further work will be required to have it tested. The framework that the authors suggest is called xUnit, and most languages have their own particular implementation of this framework. The tests should be written before the actual code, with the methods being written in a way so that they are most easily tested, which leads to a cleaner design. Code should only be released when it passes every test that has been written, which will be build the team's confidence that the work they are releasing will function properly.


In chapter 14 the authors further expand upon their ideas about Extreme Programming by stating that code should be written for intention, instead of how it works. That is, code should show what it is doing, not how it is doing it. This allows the code to easily communicate to the reader what is going on without the reader having to be acquainted with the algorithms used. As stated above, code should only be written after the tests for that code. Therefore, code should only be written when there is a failing test. The chapter is dominated by a Smalltalk example that is too large to repeat here and demonstrated the authors' ideas on the subject.


Chapter 15 concerns the process of releasing code to the other programmers on the team and is heavily influenced by collective code ownership. Each programmer being able to work on any piece of code speeds up the development process since he will not have to wait for someone else to fix a problem in their assigned bit of code. Code releasing contains three phases: local, release candidate, and released to the repository. The steps for releasing code are as follows: start with the current code from the repository, write tests for changes, run unit tests, fix any that are broken, when all pass it is called a release candidate, the release candidate is integrated into released code, run tests again, when this passes the code is officially released. Released code is guaranteed to be working. A source control system should be used to help with integration and to increase productivity. Code should be released rapidly, a couple of times per day by each pair of programmers.


Opinion
These chapters, in general, are repeats and elaboration on topics already covered in the book. The most interesting part is the long process from local changes to finally being released into the repository. It seems as though programmers would spend most of their time sitting around waiting for tests to complete. In addition, the book's list of version control systems is severely out-of-date.  



Wednesday, February 2, 2011

The Design of Future Things, Chapter 5

Reference Information
The Design of Future Things
Donald A. Norman
Basic Books, New York, 2009


Summary
Chapter five of The Design of Future Things discuses where automation should fit in our daily lives, specifically the author makes examples of 'modern' research homes where technology can be either obtrusive or seamless. Automation is enormously useful for jobs that are too tedious, dangerous, or messy for humans. Automation has also been extended to simplifying jobs and mere entertainment. The process of automation also inevitably leads to many consequences, with a significant number of these being unintentional. One of the common consequences is the additional maintenance that is required for introducing machines, but in some cases this is not so much of an inconvenience. The author used the example of the coffee maker which took away the time-wasting act of making coffee in the morning but added the necessity of making time to clean the machine, although this can be done at the user's convenience.


The bulk of the chapter describes some real research projects involving intelligent homes. The author expresses the opinion that intelligent homes that attempt to optimize its inhabitant's lives by controlling their every action will ultimately lead to failure. Instead, he proposes that houses should be augmented instead of automated by letting the ultimate decision of what to do or use up to the person, otherwise the person will end up living in the house's world. Augmentative devices need to be "voluntary, friendly, and cooperative" so that each user can use them to the extent that he or she needs while still remaining in control. Automation, as stated above, is best for situations where it may be too dangerous or boring for people to operate effectively. Full automation is best in environments where the task is completely understood and unexpected things happen rarely.


Opinion
This chapter offers very little new material since most of the author's ideas on this subject had already been expressed in the previous chapters. He discussed some ongoing research into future homes and annoyingly stated that the obvious path of technology was to basically remove most chores from our lives. I would ask the author whether many of the chores may serve more purpose than pure tedium, since I believe that these simple tasks may have a larger impact on us than simple annoyances.




Refrigerator magnets: indispensable

Tuesday, February 1, 2011

Extreme Programming Installed, Chapters 10-12

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000



Summary
Chapter 10 briefly describes what the authors term a 'Quick Design Session'. It is used on an iteration when the team is unsure of how to implement certain tasks. The design session should only encompass between 10 and 30 minutes, with the first couple of minutes being the most important since that is when most of the breakthrough and understanding will come. In the meeting, the team should quickly sketch out the simplest design that is likely to work and then immediately proceed to coding.


In chapter 11, entitled simply "Programming", discuses the various considerations that must be taken during the actual coding process. All code should be written in pairs, accomplishing one task at a time. Before writing any code, the pair should write the unit tests for that task including all tests necessary to ensure that everything that could break is tested. When the pair is finished implementing a task, the tests should be run and then the code should be integrated back into the repository so the rest of the team can make use of it. This process is called continuous integration, and ideally there would be multiple integrations a day to keep every team member up-to-date with the latest working code. The longer the time between integration and acceptance tests, the worse it will be since the peculiarities of the code will be forgotten. A key part of this programming paradigm is the concept of code ownership, or rather, the lack of code ownership. Any team member can edit any code in the system because each team member must understand how the whole system works. To facilitate this, a team-wide coding standard must be used encompassing indentation, capitalization, commenting (or lack thereof), method size, and naming. Commenting should be kept to a minimum by making the code's intention as plain as possible so that comments are unnecessary. The design of the program should be as simple as possible, following these principles: passes all tests, expresses every idea needed, no duplicate code, and the minimum number of classes and methods required. Refactoring is a useful tool for taking a complicated design and making it simpler while still maintaining functionality.


Chapter 12 focuses on pair programming in practice. The benefits of this system over individual programming is generating more and better quality code and that two people instead of one will fully understand the code. The programmer doing the actual coding is called the driver, and the other is called the partner. The partner is supposed to help spot errors and fallacies in the code, generate ideas, give feedback, and help with whatever the driver is doing even if he thinks there may be a different way. Consequently, the partner must be fully engaged in the programming process. The driver must keep the partner up-to-date on what he is thinking to keep them fully engaged, and to accept feedback from him. The least sure person should be the driver since he might become completely sidelined as the partner by not contributing because of lack of understanding. Finally, the driver and partner need to switch places occasionally to keep both interested and involved. 


Opinion
The only useful bits from these chapters are the length of the design meeting (which is surprisingly short), the use of pair programming for all code, and writing tests before implementation. Writing tests first implies that the programmer knows exactly what design he is going to use, which seems unlikely to stay the same in practice, therefore he will have to update the tests quite a bit as well. Using pair programming is an interesting concept and I wish we had made use of it in class for a project to gain experience.






Pair programming in action