Thursday, September 30, 2004

XP != Extreme Systems A recent thread in comp.object has helped me realize what has bugged me about extreme programming is not actually XP itself. In my mind i kept thinking XP should be about building systems. It isn't. XP is actually about just what it says: programming. XP addresses the programming part of any project and that's it. I am largely in agreement with the primary XP practices. Some of the secondary practices, like using a separate integration machine, are just, well, kind of silly. But most of the other XP practices are sound. And I won't say they are all just stuff i already did. That's not true. I have learned a lot from XP. Yet XP doesn't address developing a system and it never said it did. But that's always the context in which i evaluated XP and always found it wanting. A major part of systems work are things like creating a products requirements definition (PRD); complex hardware and software codependencies; stringent high availability requirements; stringent performance requirements; stringent interop requirements; specifying hardware, much of which has to be built; being compliant with many complex standards; buy or build decions; predicting staffing, budgets, and costs; and so on. None of this is programming. It certainly impacts programming. And you'll only find out some of it when you start programming. But much of it must happen before any programming happens because it is the kind of information that needs to be fed into the planning game. This is why the customer role in XP is by far the hardest role. Much harder than programming because the system has largely been figured out by the time the programmers see it. And figuring out the system is the semi mystical act of creation that seems to defy systematization. Techniques like JAD seem inadequate, but they are probably the best you can do. Just-In-Time-Requirements are good for many things, but when you need to put together a BOM 8 months before the software will be completed, you need to make an enormous amount of decisions before you would like to. Somebody in the PRD has to decide things like if your system needs to be NEBS compliant or meet 5 9s reliability and just what that heck that means on a system wide basis. Those aren't items that come out in the process of programming. And there may be 1000s of such decisions to make. Once the system has been figured out methodologies like XP and Scrum help you implement the software side. But software is just one small facet of a many sided die. comment[] 5:20:11 AM

© Copyright 2006 todd hoff. Last update: 7/11/2006; 1:06:27 PM.