This chapter is from the book
This chapter is from the book
This chapter is from the book
8. Multiple Change Requests
Problem
How can you prevent the framework from growing too complex as a consequence of change requests?
Context
Several applications use your framework. Application developers approach you with requests for additional functionality.
Forces
Regardless of how much functionality you have already included in your framework, some people will always ask you to include more. After all, if you add functions to the framework, the members of the other teams won’t have to implement these functions themselves.
But if you accept all change requests, the framework might end up overloaded with functionality. Worse yet, different users might come up with conflicting change requests, and if you accept all of them, you put the framework’s consistent architecture at risk.
You absolutely must keep the framework simple. In particular, you should avoid building the framework to run in different modes [Jolin1999]. So what should you do?
If only one application is interested in the additional functionality, that application’s team can implement the desired functions on a concrete level at a much lower cost than would result if you implement them on an abstract level.
However, if several applications need additional functionality, it’s probably useful to include that functionality—for all the reasons that justify a framework in the first place.
Solution
Accept change requests only if several teams will use the additional functionality.
What the word several means will depend on the concrete situation. If a framework is used by just three or four applications, the fact that a change request is supported by two of them can be evidence enough to show that the change request is justified. If there are more applications that use the framework, the threshold might be higher. Either way, you must make sure that you add functionality only if it is of general use, not just useful in rare cases.
The following guidelines are helpful for dealing with change requests:
- Be active. Once you have received a change request, it’s your job to figure out if it could be useful for more than just one team.
- Help users of the framework to add application-specific functions when their change request is rejected and they need to find an individual solution to solve their problem.
When a change request is accepted, make sure that it doesn’t invalidate the framework’s design. Apply refactoring techniques if necessary [Fowler1999].
Examples
The Data Access Layer Framework
The data access layer framework normally allows committing changes to the database only at the end of a session. After a while, it turned out that both the workflow system and the printing system required an exception to this rule; certain changes had to be visible on the database immediately. Given the fact that two applications requested the change, the framework team decided to offer an additional function that commits changes to the database immediately as long as these changes are atomic and consistent.
The customer system needed special search functions that allowed searching for a person with an arbitrary combination of name, phone number, address, and other data. The data access layer framework never included such arbitrary queries, since they would have been very complex to implement and they might have easily ruined the system’s time performance. Because no other team needed such queries, the framework team decided not to extend the framework but to show the customer system team how to extend their concrete application with the necessary functionality.
At some point, the framework team received several requests from different teams for extending the two-dimensional versioning. It turned out that what those teams needed could already be expressed. The desired extensions would have made things a little more comfortable for the other teams. However, everybody requested different comfort functions that, if implemented together, would have overcomplicated the framework. The framework team thus declined the change requests.
The Web Portal Framework
Of all the change requests concerning the Web portal, the first thing the project had to decide was whether they addressed the framework or any of the applications. The rule of thumb was this: Only if both applications would benefit would the change request be justified. Only a change request made by both applications was thus a candidate that the framework team would consider. This policy avoided having the applications’ functionality intrude into the framework.
Discussion
We know that building a framework is justified only when there is Concrete Evidence for Reuse (1). This pattern is in sync with the principle that functionality should be added to a framework only if at least two applications can use it. It can be acceptable to bend the rule of three a little if a technically plausible change request is made by two applications, but if the requested functionality is useful only for one individual application, it certainly doesn’t belong in the framework.