Extreme Programming (XP) has spent the past decades under perpetual scrutiny by software developers fixated on up front design methodologies. The idea behind this is simple: if you want to make sure something is well built, you must design it well first, then put it together using reliable tools. For objects such as houses, cars, or tables, of which the design evolves gradually throughout decades, the methods of up front design suffice. Computer programs, on the other hand, are products often made for an industry that evolves at higher rates than any other. For this type of environment, more dynamic methods are required, which is why XP suits as a viable candidate. How design is altered from the traditional up front design method will be discussed.
The general picture obtained from a first glance at the XP method tends to imply that design is a frivolous activity put in second-place after programming. Although programming is incredibly important for getting anything done, it is equally nothing without design as design without programming. They compensate each other for their own blunders. Programming builds the program, but leads to over-complex systems. Design leads to well structured systems, but no actual program. As such, design is not frivolous, but so is not programming.
How is it that XP actually combines design and programming in the right amounts? It tends to reiterate a certain algorithm until the project is complete: design, implementation of design, then redesigning and refactoring (Fowler). Meanwhile the design is kept simple (Fowler).
Simple is a key word in XP. In fact, Martin Fowler's essay (Fowler) seems to make it XP's core. However, what exactly is meant by simplicity will depend on multiple factors. As Martin Fowler defines it, he lists the following (Fowler): it runs all the tests, reveals all the intentions, does not have duplicated code, and has the fewest number of classes or methods. “runs all the tests” seems to imply that a program's testing such as JUnit returns with a pass. However, how exactly this applies to simplicity is beyond yours truly. “reveals all the intentions”, on the other hand, makes sense under the following train of thought: if something is simple, it is easy to understand, and therefore all or most intentions are clear to the observer. “does not have duplicated code” seems to make things easy to understand, but may not necessarily simplify a program. Finally, “has the fewest number of classes or methods” seems to be the most pertinent to the concept of simplicity. If a system consists of less functional elements than another one but holds the same...
