An Approach to Handling New Requirements

Many times in life and many times in software applications, you have to make choices about the general approach to performing a task or solving a problem. Most of us have learned that taking the easiest route in the short run can lead to serious complications in the long run. For example, none of us would ignore oil changes for our car beyond a certain point. True, I may not change the oil every 3,000 miles, but I also do not wait until 30,000 miles before changing the oil (if I did so, there would be no need to change the oil any more: the car would not work!). Or consider desktop filing—the technique many of us have of using the tops of our desks as a filing cabinet. It works well in the short run, but in the long run, it becomes tough to find things as the piles grow. Disaster often comes in the long run from suboptimal decisions made in the short run.

Unfortunately, when it comes to software development, many people have not learned these lessons yet. Many projects are only concerned with handling immediate, pressing needs, without concern for future maintenance. There are several reasons projects tend to ignore long-term issues like ease of maintenance or ability to change. Common excuses include

• “We really can't figure out how the new requirements are going to change.”

• “If we try to see how things will change, we'll stay in analysis forever.”

• “If we try to write our software so we can add new functionality to it, we'll stay in design forever.”

• “We don't have the time or budget to do so.”

The choices seem to be

• Overanalyze or overdesign—I like to call this “paralysis by analysis,” or

• Just jump in, write the code without concern for long-term issues, and then get on another project before this short-sightedness causes too many problems. I like to call this “abandon (by) ship (date)!”

Since management is under pressure to deliver and not to maintain, maybe these results are not surprising. However, with a moment's reflection, it becomes apparent that there is an underlying belief system that prevents many software developers from seeing other alternatives—the belief that designing for change is more costly than designing without considering change.

But this is not necessarily the case. Indeed, the opposite is often true: When you step back to consider how your system may change over time, a better design usually becomes apparent to you—in virtually the same amount of time that would be required to do a “standard” get-it-done-now design.

The approach I use in the following case study considers how systems may change. However, it is important to note that I will be anticipating that changes will occur and look to see where they will occur. I will not be trying to anticipate the exact nature of the change. This approach is based on the principles described in the Gang of Four book:

• “Program to an interface, not an implementation.”^[1]

  ^[1] Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software, Reading, Mass.: Addison-Wesley, 1995, p. 18.

• “Favor object composition over class inheritance.”^[2]

  ^[2] ibid, p. 20.

• “Consider what should be variable in your design. This approach is the opposite of focusing on the cause of redesign. Instead of considering what might force a change to a design, consider what you want to be able to change without redesign. The focus here is on encapsulating the concept that varies, a theme of many design patterns.”^[3]

  ^[3] ibid, p. 29.

What I suggest is that when faced with modifying code to handle a new requirement, you should at least consider following these strategies. If following these strategies will not cost significantly more to design and implement, then use them. You can expect a long-term benefit from doing so, with only a modest short-term cost (if any).

I am not proposing to follow these strategies blindly, however. I can test the value of an alternative design by examining how well it conforms to the good principles of object-oriented design. This is essentially the same approach I used in deriving the Bridge pattern in Chapter 9, “The Bridge Pattern.” In that chapter, I measured the quality of alternative designs by seeing which one followed object-oriented principles the best.