WilliamGrosso wrote: 

I'd guess that I "design" about twice as much software as I actually build. And, by and large, I don't consider it wasted effort-- a large part of that "excess design" is mapping out the tradeoffs and thinking about the potential shape of the software in revision 2 and just, in general, becoming informed about the possibilities and tradeoffs inherent in the thing I'm building. 

I view it like this: there's the thing that gets built. And there's sort of a fuzzy cloud of "possible programs" that are somehow "nearby" in program space." and I think that exploring this space, and doing so fairly early in the lifecycle of a piece of code, is a good thing. 

RonJeffries replied:

How might we quantify the value to the people funding the thing that is to get built, of exploring this space?

-----

The same question gets asked, over and over again, in the sciences. 

''Of what value,'' asks the results-oriented budget-cutter, ''is basic research? Why should we, the taxpayers, fund this? It builds no bridges, it paves no roads, it doesn't deliver the mail. What is the value of thinking about such things?''

The scientist can only shrug his shoulders and murmur vague things about history showing a payoff. That any given piece of research might not lead to anything wonderful. But that, in general, funding research is a good idea.

I think you're asking the same question. Or a variant of it. And I'm as tongue-tied as the scientists. I can't imagine trying a single solution, I can't imagine not playing around with a problem and exploring the various possible solutions. It seems obvious (but apparently isn't) that one must think about many possible solutions and play around with designs that never make it into the codebase. Even to the point of coding something several different ways and seeing which one works best and which ones are more flexible. 

See also:  the TypeInferenceStory

-- WilliamGrosso
----
Coding several different ways to see which one works is cool with XP too. We call that approach SpikeSolution. We recommend taking very short amounts of time, not building big complex full-bore things. I would imagine that's fine with most anyone.

What we XPers do in our actual implementation then may (or may not) be what's controversial. We DoTheSimplestThingThatCouldPossiblyWork. That is, of the solutions we try, we choose the simplest one that meets our ''current'' need. We try ''not'' to pick the one we think will last the longest, but the one that just barely supports the UserStory we're working on right then. Then, having made that solution work, we refactor ths system (OnceAndOnlyOnce) so that it is well-formed and ready for more change.

When we get an idea along the way as to how to "generalize" our objects, we resist doing that. We say YouArentGonnaNeedIt, and wait until we ''do'' need the additional capability to put it in. (If generalizing made the code literally simpler right then, we would do it.)

We have found, through many person-years of doing this, that things don't go in harder later, though we thought they would. We have found that more often than not, the thing we foresaw wasn't needed at all. Even when it is finally needed, we have found that we deliver more of what the customer asks for sooner, by waiting. So we keep doing it.

-- RonJeffries
----
CategoryResearch