Does (PURE) XP work for non trivial software in most practical scenarios?
Some of the XP practices don’t seem to be practical for non trivial software.
- No written requirements: - For a long running development say 2-3 years how one understands why something is working in a particular way? The typical XP explanation is code and unit test is the documentation in itself. Is it really feasible to go through the code to understand the functionality? How the user documents get created? How an end user will understand the product functionality?
- No upfront design: - Advice is develop for immediate requirement without doing the design for “speculative” need we can always refactor the code. But isn’t code refactoring adds work? Why should one “design for refactoring”? What I mean is if we know the requirement on high level why we should not design for it?
- Team code ownership (Everyone knows everything): -Probably works for a college project :-). Can this really work for reasonable size software of millions of line?
- Pair programming: - If you are a services company bill for two developers instead of one :-). Pair programming do have value when doing research, prototyping or cross training etc. But such activity is only a fraction of total time spent on a software development.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)