Build For The Future

Build for the Future is a strategy which can be employed by those who are skilled in planning and analysis. It requires a knowledge of environment, users and uses. Without such background, one builds only what one knows, or is told. Success in building requires proper foundation, structures and assembly techniques to ensure soundness and usability. It is not a "Field of Dreams", where you build it and they will come. It is rather a conscious, considered approach which entertains IntelligentSpeculation. It is what is employed when one builds a class or extends it. Structure is supplied to contain, serve, preserve and process what is needful in an endeavor. It is centered on being useful, in a manner that is usable, and in a form that is used. When considerations like this are employed, software projects are much more likely to be successful.

"Build for the Future" is one of those pieces of advice that sounds good to everyone but really doesn't mean anything. We can all agree that it is good for products to continue to provide value as time passes. But we don't agree on specific techniques to achieve that goal or on criteria used to judge whether we are on the right track.

BuildForTheFuture means different things to different people:

It can mean "Plan ahead to ensure we don't have to change it later" (see BigDesignUpFront)
It can mean "Add every possible feature that anyone might ever need someday" or "Create an architecture or infrastructure that will support every possible feature that anyone might ever need someday" (see YouAreGonnaNeedIt, FeatureCreep, FutureDiscounting, and InfrastructureCreep)
It can mean "Make it adaptable and extensible" (see DependencyInversionPrinciple and OpenClosedPrinciple)
It can mean "Keep it simple so that it will be easy to change it later" (see DoTheSimplestThingThatCouldPossiblyWork)
It can mean "Let's build a prototype that will help us understand what we really need to do." (see PlanToThrowOneAway and SpikeSolution)
It can mean "We may overrun this project's budget by implementing all these extra features, but we'll be able to make a profit on this stuff later." (see WishfulThinking)

An excellent idea, given accurate prescience. I dial the Psychic Network before designing a class.

If they were any good, they'd dial you and everything.

Yeah, but if they call you, they don't get the 1-900 fees, and they also know your attitude regarding collect calls from people you don't know (and if you did know who they were, then you wouldn't need to call them, would you?). Instead, they place ads on TV, radio, newspapers, etc., where they know in advance that you'll read them.

Anyway, I just build as well as I can for now. Modularity, encapsulation ... these things work.

Heh, heh. This is all very cute, but how do you respond to the client when he asks you why your whiz-bang new Transmogrifier can't handle left-hand widgets, an obvious (although originally un-called-for) case of extending the product? "Duh," you say. "You didn't ask for it," you say. "Didn't you think about it?" he asks. "You're supposed to be the expert," he says. "What am I paying all this perfectly good moolah for?" he asks, somewhat perturbed. Now what?

He won't ask that, because we already asked him if he wanted left-handed widgets when he asked for the original Transmogrifier. He then had the option to either have us do it now, or leave it for later.

Or, when the customer asks, "Didn't you think about it?" we reply, "I may have thought about it for a long time, but you didn't ask for it, so I didn't include it. Do you want me to start charging you for functionality you don't ask for?"

Why is the customer expecting functionality that wasn't specified in the customer's request? No matter how obvious it may be, it wasn't specified. The developer's under no obligation to provide anything beyond what was requested, and if the customer feels put out as a result, the whole relationship is in a major crisis.

To demonstrate and perpetuate negative attitudes such as some demonstrated on this page and found throughout this discipline is precisely why some customers will decide to give the development work for their IT projects to people who recognize their duty to provide skilled, substantial support and structure to the skeleton which may exist in a specification. When a provider places blame for failure upon the customer, the customer will naturally seek other providers who see the need to deliver successful products and consider the customer as being able to perceive when a product is "right".

I fall between the plan for future (beyond immediate requirements) and only-what-is-needed-now (YagNi). It is a matter of a mostly informal cost/benefit analysis. Some future-oriented preparations are free or cheap (BargainFutureProofing), such that one might as well take advantage of them. Others require more up-front building, and because the future can be hard to predict, such is often not worth it. Making such decisions is similar to "investment theory". -- top

See ArchitectTheNegativeSpace for a less spacey version of this topic...