Extreme Programming for Productivity

Extreme Programming (XP) is a deliberate and disciplined approach to software development. Risky projects with volatile requirements are ideal for XP methodology. These projects experience greater success and developer productivity. XP works because it emphasizes customer involvement and promotes teamwork. One of the most surprising aspects of XP is its simple rules and practices. They may seem awkward and a bit naive at first, but they soon become a welcome change from more formal development models. Customers enjoy being partners in the software development process, and developers actively contribute, regardless of experience level. XP was developed eight years ago by Kent Beck and has been proven at a number of companies of different sizes and from varied industries worldwide. XP is successful primarily because it stresses customer satisfaction and early customer involvement far upstream in the design process. The methodology is designed to deliver the software the customer needs when it is needed. XP empowers developers to confidently respond to changing customer requirements, even late in the development cycle.

XP improves a software development project in four essential ways: communication, simplicity, feedback, and courage. XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software from day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation, XP programmers can courageously respond to changing requirements and technology. XP itself is also different.

It has many small pieces. Individually the pieces make no sense, but when they're combined, you can see a complete picture, as with a jigsaw puzzle. This is a notable departure from traditional software development methods. Beck's thesis is that software that is engineered to be simple and elegant is much more valuable than software that is complex and hard to maintain. His example is hard to gainsay:

A typical software development project will spend about twenty times as much on people as on hardware. That means a project spending 2 million dollars on programmers per year will spend about 100 thousand dollars on computer equipment each year. Let's say that we are smart programmers and we find a way to save 20% of the hardware costs by some very clever programming tricks. It will make the source code harder to understand and maintain, but we are saving 20% or 20 thousand dollars per year, a big savings. Now what if instead we wrote our programs such that they were easy to understand and extend. We could expect to save no less than 10% of our people costs. That would come to 200 thousand dollars, a much bigger savings. This is certainly something customers will notice.^[19]

Much of what went into XP was Beck's reevaluation of how software was created. The quality of the source code is much more important than you might realize. Just because our customers can't see our source code doesn't mean we shouldn't put effort into creating something we can be proud of. Thus, XP is not really the same as "quick and dirty." Instead, it is an attempt to develop programs "quick and clean." It is especially useful for programs that have relatively short lifetimes, or whenever requirements are volatile and rapidly changing.