Simple Design

Doing that which does not have BusinessValue is wasteful.

It is helpful to know that RidiculousSimplicityGivesRidiculousResources.

The XpSimplicityRules give us an unambiguous definition of what "simple" programming is.

"I'll take a good plan violently executed now over a perfect plan tomorrow." --Gen. George Patton

"If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy. Put in what you need when you need it." -- KentBeck, in ExtremeProgrammingExplained

If you believe you've done it before and know what you'll need then not putting in the functionality is crazy.

In the end, it is very possible that the future is uncertain in surprising ways. Try programming with a YouArentGonnaNeedIt mentality and see if you don't surprise yourself.

Even when you're right, here are a few reasons why it might still be a bad idea to work for anything but the current story, in increasing order of importance:

KentBeck makes another interesting point in ExtremeProgrammingExplained, which is that early, unused functionality charges interest. If you spend $1,000 putting in a feature today, and it doesn't become useful until a year from now, you've wasted the interest you would've made by investing that $1,000 elsewhere.
You will [hopefully] know more later than you know now. To work without this knowledge is to wantonly cripple yourself.
Speculation makes a judgment on what has BusinessValue. The customer has stated which the most important stories for the iteration, and the developer has chosen to do differently. Usurping the customers decisions is the kind of thing that justifies MicroManagement. (Note: this only applies to doing work for stories beyond the current iteration. Within the iteration, developers priorities are the only thing that exist.)
Solving problems is hard enough without having to solve many problems simultaneously.

In how many projects is change cheap and easy? In a small band of programmers it may be, but not in large organizations and large projects. --AnonymousDonor

The contrasting XP claim - a claim specific to XP, as opposed to the claim that people don't know the future - is that changes are always cheap, whereas bugs and complexity are costly.

The cost of change is proportional to the quality of the people, not just the number of people. -- JbRainsberger

I didn't know certainty was a requirement, I thought I could use my rational mind and weigh risks. Most of my life activities I have done before, like shopping, driving to work, making dinner, etc. I pretty much know what I'm going to do for each of these activities. I have a plan that usually works even though the future is uncertain. I realize the future is uncertain and have confidence I can respond to changes, but that doesn't mean i give up on planning because the future may surprise me. With experience much of software is like any other well known activity. That which is uncertain can be rapidly prototypes and handled. That you must not plan because you are not completely certain strikes me as irrational and it's now how we run 99% of our lives.

But, when you plan to go shopping, you don't decide in advance which lanes of the street you'll be driving, exactly which aisles of the supermarket you'll be traversing, or the exact contents of the shopping basket when you reach the checkout line. You have a very simple, high-level plan that you refine as you execute it. That is how people run their lives.

In XP you would not go shopping unless your customer told you to, so it's likely you would starve. Even if you did want to go shopping your first step would be something like "go to door," you wouldn't even be thinking about what would happen after that even though you know perfectly well what the next steps are. And when you get to the store a little girl points at you and says "mommy, that programmer is naked." At which point you say, "Our customer thought clothes were not required." Or you had to run back home and start all over again. :-)

I can tell you that in a large organization if you don't get your design in now, it's never going in because there is never a right time. In a small group you can do anything you want and it will work out. Once you go large everything changes and changes radically.

Are you sure it's the size of an organization that determines its flexibility, or do large orgs typically have more inflexible cultures?

I like the idea of SolvingDesign , in the sense of asking yourself 'how does the design solve both the immediate and known future problems?'. is it a short-term or long-term solve? I agree that adding future requirements that may not be used, is not beneficial, but refactoring 3 or more times to get to a place you had expected to get to, is also costly. Judgement needs to be made on the BusinessValue of SolvingDesign - How robust is the solve I am implementing? Is there BusinessValue in 'minimally' catering for it now, to alleviate some of the stress of future changes? - JonathanCrossland

CategoryExtremeProgramming