Design and Code in Small Iterations
In his book, Beck makes some admissions that you don't often hear from software developers:
- Writing code is hard.
- Many software projects fail.
These are not the projects that people go trumpeting about at conferences and user groups. Sometimes they fail due to bad management (well, that you'll hear from developers) and sometimes they fail because of bad coding (and that you don't hear). Sometimes they fail because of a bad initial concept or design, sometimes from trying to do too much with too few resources.
XP attempts to address all these pitfalls. If a project is doomed to fail, you need to find out fast before large sums of money are wasted. Instead of spending time creating an all-encompassing design and sending the programmers off for six months to implement it, design and code in small iterations and deliver the simplest thing that could possibly work.
XP also espouses constant integration of new code into development versions of an application. It advocates small, frequent production releases for customers and end users. Because of this, customers and users also take a more active role in an XP project. With small, frequent design iterations, customers are constantly involved in the design process. XP advocates having a person in the role of the end user on the project team. It also encourages real-world feedback by getting a project into production with real end users as quickly as possible.
Sometimes XP takes the myopic view that everybody finds software as fascinating as developers. Many end users don't want their applications to look and work differently each time they use them and would not favor frequent small releases. Most people are not interested in using beta versions of software and may, in fact, get an irreversible bad impression.
Some people might argue that if your design is changing too much for an up-front specification, your project is already in trouble. While technology may be changing rapidly, it's not changing significantly every three weeks. Also, there is a tremendous overhead (can you say "meetings"?) in perpetually tweaking the design of an application. XPers rebut that experience shows that applications rarely look like their initial specifications, and those that do lack flexibility. If you are sailing to India, you need to lay out a general course. But you can't possibly anticipate all the changes in currents and winds along the way, so don't bother trying. XP says don't commit until you absolutely have to.