Build For Today Design For Tomorrow

Pattern Name

Build for Today, Design for Tomorrow

Problem

How do you handle present requirements efficiently in the face of future requirements?

Context

Developers building or extending a system

Forces

Future requirements are sometimes not fully understood and are highly subject to change.
Efforts in reuse often lead to elaborate components that are not only not reusable but often fail to be completed.
It is often difficult to differentiate between what is a ‘future’ vs what is a current requirement.
Developers tend to look at problems as coding problems only and fail to consider the power of design to provide solutions to their problems.
Object Oriented languages provide ways in which to build flexibility through mechanisms such as virtual methods and templates; unfortunately, many developers do not properly utilize these tools.

Solution

Always write needed code in the implementation. Always ensure that the architecture is flexible and extensible so as to be able to engage envisioned scenarios.

Resulting Context

A system that meets existing requirements and is capable of addressing future requirements when necessary. The cost to add these new capabilities is often less than if an up-front effort had been made.

Rationale

By separating implementation from design, we properly address higher-level problems more effectively and deal with them properly. When the architecture is robust, we can forgo the implementation of the presently unneeded and can concentrate on implementing the features solving present problems. Some features included in systems because they are supposed to be needed (but are not needed now), are not now implemented and perhaps never implemented. Other features may become needful due to market forces. Because the architecture has been made extensible, these new features can be handled easily.

Known Uses

Used in several architectures developed by this author - including the framework for Databoard, an embedded medical data collection device.

Related Patterns

SinglePointofDocumentation?
DesignForTodayBuildForTomorrow?

Sketch

N/A

Author

BrandonGoldfedder

Contributors

DonaldNoyes 20050327

AurelianoCalvo 20060307

Date(s)

5/29/96, 10/1/96, 3/27/2005

How do you draw the line between code and architecture? What does it mean that an architecture can engage all potential scenarios?

First example: Let's say that you are coding an application which uses check-out register data as a basis for reordering and supplying inventory for a chain of grocery stores. The architecture allows for all the registers and stocking configurations which might be possible in an existing store as well as for future or expanded stores in the chain. The code deals with what exists now, the registers, the stockable shelves, the reserve storage space in each store and warehouse, the existing delivery options including trucks and drivers, wharehousemen, etc. In other words, code deals with the operational details, whilst the architecture deals with potentialities.

Another example: A telephone company is constructing a central office which will house the switches and other supporting equipment in a growing city. It starts with a six story building, but provides via foundation and structure of the first six stories for the ability to add an additional 24 stories for future equipment and connection mechanisms such as microwave relays on top of it and and provision for future cabling from overground and underground cabling between floors. (including future floors). [This is an actual example for a building existing in Kansas City, first planned over 40 years ago, and active now with state of the art equipment, now approaching the planned possible height].

It's surprising that newer telco equipment requires more space than older telco equipment.

Only if you fail to consider how the equipment differs in performance and the number of users served by it.

[I'm still not sure I understand the difference between CodeVsArchitecture. Separately, how is this pattern different from RobertMartin's OpenClosedPrinciple?]

Does this pattern apply to source code? My opinion to this pattern is that it is a DarkPattern and should be avoided (unless you can predict the future). One should design for today. Id est, to have a minimal design. All parts should have a purpose for the current requirements. -- AurelianoCalvo

This is a slippery slope, and should not be followed to the extreme - see PrematureOptimization and DoTheSimplestThingThatCouldPossiblyWork

See: ArchitectTheNegativeSpace

CategoryPattern