"XP distilled" revisited, Part 3: Realistic development

Return to article

It's shocking to me that software development teams still behave as if they can know everything at the beginning of a project. They still try to freeze the requirements specification. They still try to stifle change during the project. They still try to design everything at the beginning, leaving no room for learning later on. I can understand the desire for control, for stability, for simple sanity. But trying to set things in stone at the beginning isn't the way to get those things. Change will happen, guaranteed. The team will learn, I promise. Ignoring that is unrealistic. XP doesn't ignore it. Here's how:

  • The YAGNI (you aren't going to need it) practice tells me to take a relatively short view on design, because what I'll need tomorrow will probably be at least a little different than I imagined.
  • The release planning and iterations practices tell me not to plan too far ahead, because the landscape will change as I drive and I'll need to adjust course as necessary.
  • The frequent releases practice tells me that concrete feedback from real users is more important than perfection -- get software in people's hands and let them use it so they can tell me how to steer.

XP focuses attention on what you can know for sure at every point. I have never experienced more realistic software development.

Return to article