Thoughts on Extreme Programming

A popular trend in systems development circles is the so-called Extreme Programming Paradigm. XP has proven to be quite effective at rapidly producing system functionality, and it includes many practices that should be considered by any development team (e.g., Test Driven Development or TDD). However, there are many pitfalls to XP that don’t necessarily make it the best technique for many organizations. Extreme Programming is a technique that is used to much profit by many organizations today. In contrast to the more “rigid” documentation guidelines outlined above, Extreme Programming is characterized by a much more streamlined time-bounded development process. Typically developers work in teams and communicate directly with the stakeholders. They then choose a part of the problem to focus on and develop something in a fixed amount of time; to the degree that features cannot be accommodated within the stated time frame (often weekly, sometimes monthly), these features are ignored in order to have something to show. The stakeholders then inspect the result and suggest modifications or improvements to the developers who continue with the process until the stakeholders are satisfied. While this can be very effective at showing progress in the short-term, it suffers from a lack of long-term memory. Over time, stakeholders change or original goals were forgotten. Extreme Programming is best suited for ephemeral projects, such as a consumer-facing website, that often don’t have a lifetime beyond several months. It is inappropriate for corporate development of mission critical systems that have complicated requirements and whose stakeholders can change over time. Successful corporate development efforts borrow the best practices from Extreme Programming, such as Test Driven Design and Pair Programming along with the most useful of the Waterfall design practices, such as the reliance on use cases and functional specifications, to create lasting products.