Art Of Choosing The Next Card

In JavaVersioning, someone said What I meant was this could imply that, to protect yourself against potential future clashes (which, as a true XP'er, one should ignore), you localize and hide object creation behind some factory interface.

This seems to imply that if you program extreme, you will ignore important design considerations. This isn't true. In fact, quite the opposite. Programming extreme allows you to grapple with important design decisions sooner than BigDesign-styles by clearly prioritizing the decisions, in the form of the UserStory's.

A story from JavaVersioning was hot update of client code. If the PlanningGame identified this as a story with high business value and high technical risk, it would be implemented early in the process, perhaps even in the first iteration. If a factory-like implementation was the SimplestThingThatCouldPossiblyWork, that's what you'd do.

There is an art to choosing what order you address cards, whether you are talking about

the order you implement UnitTests,
the order you implement EngineeringTasks in an iteration,
the order you implement UserStorys in a CommitmentSchedule,
or the order you implement clusters of related UserStorys in successive releases.

Getting good at picking the next card is one of the highest leveraged and most difficult to explain skills in XP.

Which doesn't keep me from trying to describe it here.

-- KentBeck

Case analysis

Low priority/low risk- don't do it
High priority/low risk- do it soon
High priority/high risk- do it now
Low priority/high risk- this is the NerdsDilemma?.

You know, you just know, that the customer is going to want XYZ tomorrow, they are just too blind to see it. And if they want XYZ, then you'll have a lot less work to do tomorrow if you just add this design feature or that today. I teach my team to take a deep breath and move on, because more often than not XYZ doesn't happen, or if it does happen, fixing the design is easier than I can imagine today (I'm smarter), and anyway it is bad practice for programmers to second-guess customers. It is the first step on a slippery slope to the programmers being in charge, which we know doesn't work. -- KentBeck

What to do when the DevelopersAreTheCustomer? -- MarnixKlooster

The example in JavaVersioning was actually about managing clashes between versions of a package, so regular code would meet the users requirements just fine. If, say, the users did not believe that the code would be taken by anyone else but you, from your long experience in the company, just knew otherwise, wouldn't that make for a case 4? Taking the time to provide support for version clashes in code that won't need it just now seems to me to break DoTheSimplestThingThatCouldPossiblyWork. By the time the pain happens, it's all been packaged up and there's no-one left to change the code your currently developing. -- SteveFreeman

Steve and Kent, is there some confusion about what to do in case 4? I thought Kent was saying "don't do it", but Steve seems (to me, at least) to be interpreting it as the opposite. Actually, I answered my own question, because I am confused! [Delete this note after clarity is achieved or I am deemed hopeless. ;)]

There is no confusion that I can see, just disagreement. High technical risk/low business value means I don't implement it. Period. Because it works better for me that way. I read Steve's comment as saying he does implement in at least some of these situations. I assume because it works better for him that way. -- KentBeck

I agree with Kent that I disagree ... Or, to be more precise, I'm nervous about how extreme one can be with this level of thing, because we've all had difficulties mixing and matching libraries we can't change. I suppose it's a matter of judgement and that's why (you hope) that experience can be useful in the business. -- SteveFreeman

Seems to me the same tail-chasing as trying to RefactorMercilessly a database schema after it has been put into production. You just don't. Because you just can't. So you just put the hooks in to move it when you need to. Same thing with a published class interface, or a file format, or anything that moves out of your RefactoringRange?.

I suppose this has to do with that deferred option pricing bit in ExtremeProgrammingExplainedEmbraceChange. Eventually you have to make a decision. You just want to push it off as long as possible. With refactoring, you never make a real decision. But as soon as you can't refactor any more, what you have is your "decision." You can either be wise about this and apply some lookahead, or you can try to "adapt" later with a solid rock in your stomach instead of warm milk. -- SunirShah

CategoryPlanning