Dont Limit Your Options

[From InfrastructureInXp, where it was stated that an early commitment to infrastructure may limit your options. (IE: You won't be able to replace a 3rd party product.)]

Proposed Rule

"Before committing to an infrastructure/product/architecture, make sure that you can go back without exorbitant costs (e.g. by building an appropriate abstraction)."

Doesn't this advocate PrematureAbstraction? -- HaskoHeinecke

Well, it shouldn't. Premature is before you need it. The above statement advocates to build an abstraction as soon as you need it (and gives an indication when you may need it). "Don't swing the bat until the ball gets to you, and don't swing it afterwards either." (YogiBerra?) -- DierkKoenig

I disagree. The sentence goes: "Before [...], make sure [...] (e.g. by building [...])." I think this quite clearly expresses that there is work to do up front on the vague assumption that a particular kind of change is going to happen some time in the future. By the way, let me stress that our argument is whether DontLimitYourOptions means PrematureAbstraction, not whether any of those are good or bad ideas. -- hh

DontLimitYourOptions does not necessarily mean PrematureAbstraction, but can mean abstraction.

 PRE: We want to commit to infrastructure, architecture or else.

 if (we can change decision later without exorbitant cost)
return doCommit
 else
if (there is a way to still keep our options)
return that way // may be an abstraction
else
return we have limited our options

-- DierkKoenig

Interestingly, your "code" above says I have limited my options even when I do nothing at all. ;-)

: To "do nothing" is a decision that can be reverted easily by applying the reverse action (do something). Therefore it fulfils the condition in the if statement. We doCommit to "nothing", not limiting our options. :-)

I feel that a PrematureAbstraction actually limits your options.

For me, DontLimitYourOptions is a prerequisite for EmbraceChange. It keeps change possible to happen.

So we have to talk about what DontLimitYourOptions is supposed to mean. If it means you have to actively introduce abstraction or other kinds of additional complexity to your code in order to preserve options, I say this is definitely and explicitly discouraged by ExtremeProgramming unless proven necessary. I also believe this is what was meant by the original statement at the top of this page.

There is also a more vague interpretation of DontLimitYourOptions, meaning don't make rash decisions towards an e.g. infrastructure because that may limit them. I agree with what PeterGassmann said in InfrastructureInXp that ExtremeProgramming provides not much guidance in that decision. But I also think this interpretation is not what was meant by the statement at the top of this page. -- hh

[So we have to talk about what DontLimitYourOptions is supposed to mean.]

As I understand XP, it is based on keeping change possible. I have the option to go this way or the other. That enables me to respond to the feedback I get from my customers, from the system and from the team.

Xp is also about simplicity. But abstractions make solutions less simple.

Therefore: I look for the simplest solution that still keeps my options.

First choice: check whether you can defer the decision. (can also be worse than anything else, but still...)

Second choice: You found a way that keeps things simple and options open? Super! Go ahead!

Third choice: You have to trade-off between sacrificing simplicity to a certain extent and walking handcuffed into a possible dead-end. Your choice.

I would suggest that before one can limit (or allow) options, one must KnowYourOptions?. To include as one of them the option for accepting and providing a framework for changes should certainly be one of the Options. It should be recognized that Options should be enumerated as complete as possible and clearly stated.

This principle should be qualified as "Don't Limit Your Options Until Necessary". That turns it into one of those obvious self-correcting rules, but you can't make any progress without limiting your options. Limiting options is a necessity.

When you first start a project, you have a blank slate and all options are available. As soon as you write a single line of code, you have eliminated a lot of your options. The second line of code eliminates more options, and so on. You are finished when there is nothing left to add, and nothing left to take away - that is, when you have finished choosing between options.

Trying to keep all one's options available usually inhibits progress. It leads to AnalysisParalysis and bloated overly-abstract designs. In contrast, simple designs result when you make choices and stick with them (unless different choices appear better later).

That's where the XpCourageValue comes in: you have to be willing to commit to your choices. Making choices early means that you will find your mistakes sooner. Putting decisions off until later often leads to nasty surprises.

It seems that an abstraction should be added JustInTime to wrap (WrapperPattern) the new component that might limit your options. By adding the wrapper just before adding the new component, you avoid PrematureAbstraction and adhere to YouArentGonnaNeedIt. But, by wrapping, you also DontLimitYourOptions very much. You can change the implementation (select another component, write your own, etc.) without touching its usage.

I did this to incorporate log4net into my infrastructure. Only a handful of classes depend upon log4net itself; they isolate the rest of the system from that dependency. When I upgraded log4net to a new version, I had to touch only a couple of classes. Plus I was able to add to the interface without touching the log4net source. I successfully avoided PrematureAbstraction while adhering to DontLimitYourOptions. I am confident that I could swap out log4net completely without breaking the rest of my system.

-- RobWilliams

Back to InfrastructureInXp