Pattern Name: High Road Development 1
Problem
How do you handle existing requirements efficiently in the face of changing and future requirements?
Context
Developers build or extend a system.
Forces
Future requirements are often not fully understood and are highly subject to change.
Efforts in reuse often lead to elaborate components that are not reusable and often fail to be completed.
It is often unclear and easy to lose sight of what is a "future" vs. current requirement.
Developers tend to look at any problem only as a coding problem; they fail to consider the power of design to solve these types of problems.
C++ and other 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
Never write any unneeded code in the implementation; instead, transfer the effort to design. Ensure that the architecture can handle all potential scenarios (realistically, as many likely ones as possible). This is a rather lofty goal, but movement in this direction is essential. Rather than hardcode in code that is rigid, utilize design patterns and other mechanisms to allow the system to expand through additional variations rather than through change. In addition, avoid the use of any stub code or other placeholder where an additional level of indirection and application of a pattern can allow the solution to be more readily solved.
Resulting Context
What results is a system that meets existing requirements and is capable of addressing future requirements when necessary. The cost of adding these new capabilities is often less than if an up-front effort had been made. This is especially true when we don't know up front the exact requirements (otherwise we might have done it initially), so our up-front efforts are often wrong or result in development toward a less optimal design. One area to watch carefully when applying this pattern is the resulting potential increase in design complexity (although not always coding complexity).
Rationale
By shifting the focus from implementation to design, we can solve higher-level problems more effectively and often dismiss the problem entirely. Often the features that the system is supposed to handle are never implemented, and other features come into existence because of market forces. Normally these new features can be easily handled since the architecture has been made extensible.
Aliases
Build for Today, Design for Tomorrow
Known Uses
This pattern has been applied to several large frameworks that I developed. One example is Total Commissions Systems (TCS), an enterprise-level commission calculation system. In this specific system, the application of this pattern allowed us rapidly to redesign the core calculation portions between Versions 1 and 2 to decouple the hardcoding to a plug-in architecture. This change took a matter of days and avoided significant ripple throughout the system.
Refactoring and Extreme Programming
Refactoring [Fow, 99] provides an alternative approach to using this pat-tern, and, if a sufficient testing framework exists, it can be utilized success-fully. A fundamental idea in refactoring is to focus on simplifying design and to provide an environment for continual evolution (rather than extension) as new equirements emerge. When an approach that is based on refactoring is used, a development approach, such as Extreme Programming Explained: Embrace (XP) [Bec, 00], should be considered. From a very high level, XP is a team-based approach in which the divi-sion between the different cycles blurs because of an extremely reduced time frame for each phase. This approach is just beginning to gain some attention (although similar processes including RAD and Just In Time pro-gramming have been used successfully for many years). XP seems to work well for in-house projects in environments of high risk and change where standard processes may fail. I think it also works best with teams consisting of more junior programmers.
This is a very controversial approach, and I'm still at the investigation stage of this process. I have found much with which I disagree, mainly because of environmental issues in the type of development I've observed, but I enjoy anything that makes me question what I thought I knew. I highly recommend learning about this approach. Beck's book [Bec, 00] is an extremely quick read and raises several questions about the process of developing software. Regardless of the process or specific approach used, the approaches discussed in this book should be fundamentally considered when building any software systems.