When In Doubt Leave It Out

I believe that there are many, many, examples where you really do know that you're gonna need something. Plainly in a number of instances you're going to be wrong, but I've worked with experienced programmers who were right far more often than they were wrong when it came to things like this.

My approach is to challenge every 'extra' function someone proposes - Make the developer prove that we're 'gonna need it', and talk to the customer to find out what they think. This is important because if they are right then in many cases you will absolutely save time, and often the cost of being wrong is very low.

There are cases when a small incremental effort now can save a shed load of time later, but in the spirit of XP and simplicity I believe the approach should be that where there is any doubt about the likely need for some function

-- GaryBarnett

This is too weak of a heuristic for XP's purposes. Most people would agree that if you have any serious doubts that you'll need something, it would be a waste of effort to do it, if you're pretty sure you won't need it, unless the customer asks for it, etc. Way too WishyWashy? for XP. The rule is YouArentGonnaNeedIt, because in the vast majority of cases, you won't. If you really think you will, get the customer to make a story for it. That's why we have UserStories. If it's not on a StoryCard, how can you argue that you'll really need it? If you've got a half-decent argument, why isn't it on a StoryCard? These distinctions and separations of responsibility are important to make in XP, because they foster communication between the development team and the customer. Don't make any guesses, because some of them will be wrong and the GoldOwner won't be happy with the consequences. -- AnonymousDonor

I disagree with your notion that in the 'vast majority of cases you wont need it' - Take the example of an experienced developer with 3 years on a project, I'm willing to bet that he or she will know the business, and the application, sufficiently to narrow those odds in a major way.

The really ticky thing when trying to raise comments and concerns about XP seems to me that in most cases I don't disagree with the basic principles, just the rather extreme way they are applied ;-)

Could I, respectfully, ask people to add their names to contributions - I have no intention of flaming people - I'm keen to discuss this stuff in a sensible way. GaryBarnett

Contributions don't really need names as the names will eventually be refactored out, they do however aid in developing the idea of discussion. In some sense unsigned contribution to a discussion are a bit not using your RealNamesPlease -- AlanChristiansen

The (now) 'Anonymous donor' above raised for me what is another issue about the stuff hidden and unstated about XP. The question was asked why don't I have a user story if I claim I can make a case that we will need it? Answer, I dont have all the user stories yet. Does XP Assume that I have? Where in the XP process do we estimate just how flaky our user stories are, and what the risk of radical change is. How and when in XP process do we decide that the user stories are still way too flaky and that we should first mock up a smoke and mirrors prototype.

Does XP have an exclusively binary notion of a user story. ie We either have a user story Which could implement with some confidence of hitting the target or we do not. Does XP deal with the notion that all we currently know is that we want to do something like.....?

I have, in the real world, had user stories like, 'Once all that data is preprocessed into useful formats, then we will do clever things with it.' Sometimes the previous user story to that one was, 'Here is 40 Gig sample file (with corruptions), here is some out of date documentation, process the data tell me how much is salvagable and intelligible and tell me what else you find, then we will decide what to do next.'

If I really had all the user stories and they were not going to change then I could really do BigDesignUpFront. (I am clever and experienced after all.) Real Users in my experience only finally start to understand what they really want when they see the first prototype.

Experienced programmers knows things like, all systems this complex eventually need an extensive logging system to track and validate what has been done. Sometimes users do not believe you, until later.... Note like anonymous donor said, this is REALLY dangerous, down this path lies delusions of grandeur.

Sometimes the current set of user stories could well be satisfied by a SimplestThingThatCouldPossiblyWork but you just know that the stories are going to change radically and expand, so this currently simple application needs some serious framework and apparently excessive flexibility in the design and metaphor to cope with the expected changes to the UserStories.

I suspose you could argue against the above two points but you will be spitting into the wind. They happened. That was the reality, get used to it, and have a software process that deals with them too.

In some ways these issues are addressed by OnceAndOnlyOnce which effectively promotes reuse and good design. In the same way that WhenInDoubtLeaveItOut is too weak of a heuristic for XP's purposes, OnceAndOnlyOnce is a necessary but not a sufficient motivator to produce a design with the room to change that some developments need. The large bank of unit tests provides developers with the courage and certainty to refactor effectively. This greatly reduces the cost of change, but that alone is not enough.

--AlanChristiansen

--- Same author different perspective.

I wonder if the issue I am addressing could be dealt with by getting the user to agree to one more Story. I want everything I said so far, I expect to change my mind about what I have said, and also add new features I have not even thought of yet.

In this situation, then this last user story says that the simplest thing that could possibly satisfy all the other stories, is probably way too simplistic, and the architecture needs to stay more general and use a very flexible metaphor.

The last most flexible metaphor I used was: 'We are going to do things, in order, at specific times using resources, that will have rules regarding what is and is not legal.' 'There will also be a GUI that allows the what when and how to be specified and then monitor the progress.' Large slabs of this code are reusable for any project that can be described thus. This is not SimplestThingThatCouldPossiblyWork , IFF we knew all the user stories. At a point that was more than half way through development we still knew we did not have all the stories. One set Stories in particular was entirely missing, and was of the known form, 'Once we have collected the data, then we will err, um, work things out'. This skeleton still had no more bones than that. Why ? No one had ever collected the data in these kinds of quantities before! In the past it had literally often been done with pencil and paper by our Users.

--AlanChristiansen

Many critics of XP isolate the individual practices and find their weaknesses, then claim that XP is invalid because each individual practice, on its own, has major flaws, drawbacks, and gotchas. KentBeck, in the original XP book, has already acknowledged that each practice on its own isn't enough. BookXp requires that all practices be performed together so that the weaknesses of one can be covered by the strengths of another. I think the fact that Kent chose to declare this as a requirement was a smart thing to do for the survival of XP. It makes it really hard (but not unreasonably hard; it just takes practice) for someone to claim that they actually do XP. This protects XP from those who half-heartedly try out a couple of practices and then claim WeTriedXpAndItFailed. I think this insulation has been a major factor in XPs success over other AgileProcesses. It's not that the other processes don't work, it's just that with XP you don't get a horde of FalseNegative?s.

What I'm leading to is that there are support practices for YouArentGonnaNeedIt, and UserStories, and in fact, each practice has several support practices. It's like a well balanced team. Each player has a different role, yet they each support each other in a variety of ways.

How do you know when the UserStories are flaky? Well, part of the PlanningGame is that you (the programmer) have to make estimates for each of the user stories, and each estimate has to be able to fit within an iteration (ideally, you should break a big one like that down even further). If you cannot accurately estimate it, or your estimate doesn't fit in the iteration, then the story is too big and must be split into two or more smaller stories. Another way to tell if a story is flaky is to ask the customer to write an automatable AcceptanceTest. If that process is difficult, then the story is flaky and needs to be refined or split. Another part of the PlanningGame is that the customer chooses the order in which stories are implemented. Thus, you should have stories that talk about one thing only, and they should not be temporally linked, so that the customer can place them in any order.

And yes, you are right, the customer won't know what they want until they see the first prototype. That's one of the reasosns why iterations are short (only 2-3 weeks), so that we get the first prototype as soon as reasonably possible. The customer cannot ask for more for the first than can fit in one iteration, which is impossible to confirm if the stories are flaky.

Bottomline, if the stories are flaky, they're probably not XP UserStories, so go back to the PlanningGame and try again.