TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Refactoring is one of the most interesting ideas of agile development. In essence, refactoring involves the constant redesign of the entire OO class hierarchy, and methods such as new requirements come to be known. Agile development programs evolve through iteration. At each release, new requirements are introduced. Each new set of requirements mandates that the programming team go back and design these new requirements into the existing code.
Refactoring goes hand in hand with the idea of minimal requirements. One of the basic tenets of XP, and therefore, agile development, is that of implementing only those requirements that are known for certain and that are involved in the current release.
Historically, one of the problems with radical iterative design is that after a number of iterations, the program(s) becomes increasingly difficult to maintain. As change after change is added to the program, it becomes more and more difficult to understand. However, with the idea of refactoring, the design is revisited at each iteration, and changes are integrated, thus making the systems evolution smoother.
In my opinion, refactoring is one of the key ideas of agile development. If agile development's form of iterative development with minimal documentation is to succeed, then there must be an increased emphasis on design. Refactoring really means design/redesign.
Early versions of OO design emphasized spending enormous amounts of time designing class hierarchies and methods before building an application using the classes and methods. But this made early OO very front-end loaded. A great deal of time was usually spent on the initial classes, only to discover that you always had to redo them as the project progressed and you learned more about the problem. In OO, this became known as "class thrashing."
In agile development, there is minimal design up front, but that minimal design is repeated for each iteration. The belief is that if you do it right, the program will improve, not degrade over time. There are some difficulties with this approach, however. For one, manually refactoring OO code is not an easy task, and, for another, some kinds of refactoring (i.e., data refactoring) are much more difficult than others.
Unfortunately, even though agile development, coming as it does from OO, is a highly technical approach, there is little discussion about the importance of automated tools in such critical areas as class and method refactoring. Because of the property of inheritance, changes in one class often ripple through a system in unpredictable ways. Recently, tools have begun to make this process faster and more reliable.13
Class and method refactoring are only one part of the problem. An equally large problem that has been largely ignored by agile development is the importance of data refactoring. Most of the major problems associated with redesign occur whenever it is necessary, for whatever reason, to redesign the underlying database. Historically, OO design has been somewhat light on database design and redesign. In the analysis section of this report beginning on page 14, we will discuss both the importance of data refactoring and automated refactoring tools, of which automated database redesign tools are the most important.
Agile . since Jun 23 . Index . DOCs TOP TOC
Pair programming is just what it sounds like -- all programming should be done by pairs of programmers working so closely together that one can pick up and/or modify the work of the other at any time.
Agile developers maintain that pair programmers working together are far more productive over the long haul than two programmers working independently. They maintain that by working in tandem, the design of each part of the code is made more clear and easier to comprehend and that, by working in pairs, individuals learn better habits and produce more than they would on their own.
The pair programming approach institutionalizes the practice of code reviews. Each day, each pair programmer must understand all of the code that he or she is responsible for no matter which partner writes it. Agile development maintains that the result is better, producing tighter code that is easier to understand. Used in conjunction with test-first development, pair programming speeds the development process by forcing both programmers to use the same (or at least a common) design strategy.
Pair programming in an agile development or XP environment creates an atmosphere where people know more because they are involved more. According to Beck, "If two people pair in the morning, in the afternoon they might easily be paired with other folks. If you have responsibility for a task that is unfamiliar to you, you might ask someone with recent experience to pair with you. More often, anyone on the team will do as a partner" [1].
Pair programming is knowledge management par excellence. By making sure that for every function there are two people who completely understand what is going on, there is far less reliance on one key individual who might leave, get sick, or otherwise become unavailable.