Prevention

---

Over Simplification is prevented primarily in the design stages of development. Once the coding begins, the distribution of complexity is likely to take a life of its own and require redesign and refactoring to fix. This does not mean that there are not opportunities to prevent Over Simplification while coding, just that it is simply less common.

Completeness

When we talked about Complexification we emphasized the importance of a minimal interface and simple implementation, but that was only half of the equation. Completeness is also necessary to produce the best design and implementation. A minimal and complete implementation will require the least maintenance and be the easiest to maintain.

The concepts of minimal and complete might seem at odds. This is not the case, but they do represent a balancing act. Added unnecessary functionality will make the application more than complete and therefore not minimal, whereas failing to provide necessary functionality will make the implementation more than minimal but fail to be complete.

Thus, a fine balance must be maintained in order to take advantage of the benefits of both simplicity and full functionality. Additionally, this balance might shift as changes occur to the design and other implementations in the application. This requires the flexibility to refactor the interface and implementation to restore the balance and continue to provide the best maintainability for the object.

Realistic Design

In order to create an implementation that is minimal and complete, the design that the implementation is meant to fulfill must be realistic. If you plan to write an application that does everything, you will end up with an overly complex implementation. Other programmers and perhaps even you will not be able to take advantage of the functionality included because it is obfuscated by the complexity of trying to understand its use. This usually means that you must aim for less than you would like to accomplish. In fact, you should generally aim for less than your first estimate of what you can accomplish.

On the opposite side of the design problem, do not try to get away with too simple of a design. An overly simple design and implementation will leave the missing functionality out, and this will not be discovered until later in the project. As with any changes later in the project, increasing the complexity of the design will result in a substantially higher cost.

Perhaps at this point you are still thinking that you do not want to end up implementing unused functionality. However, you must look at it from a more long-term perspective. A good analogy to draw upon is David Sklansky’s discussion of winning at poker [Sklansky87]. Poker is about winning over the course of multiple hands, and even across an entire lifetime of playing poker. If you make a bet when the odds are in your favor, you have made money whether you win or lose that particular bet. If you make a bet when the odds are against you, you have lost money whether you win or lose that particular bet. The reasoning behind this is that by averaging the money won and lost across time, only betting when the odds are in your favor will result in a profit, whereas only betting when the odds are against you will result in a loss. Poker is not a game of individual hands, just as software development is not a matter of individual classes. While you might occasionally implement extra functionality at the beginning that loses some time, you have in reality won by saving the much higher late development costs in many other instances.

Winds of Change

The other reason for implementing functionality that is not of immediate use is to reduce the impact of likely changes. In software development, changes to requirements and therefore design are inevitable. However, some of these changes are more likely than others. By incorporating design elements that anticipate the most likely changes, you are once again betting when the odds are in your favor. Whether the particular change happens or not, you have made a winning choice.

Preparing for change is useful at any point during development, but it becomes of particularly importance toward the end of the project. At first, it might appear that anticipating change is most important at the beginning of the project. While it is true that anticipating possible changes early will save development time, unanticipated changes can be dealt with if there is still time remaining. As the project end nears, however, the impact of any change is magnified. If a change becomes necessary that is not easily made to the current code base, the project could be delayed, or even worse, canceled.

Determining what changes are likely is really a two-step process, starting with asking the customer what they expect will change. In this case, the customer does not necessarily represent the end user. It might be a manager to whom you are responsible, or another project that will be using your code. There is a definite benefit in reducing the number of people between the end user and the programmer, but having them talk directly to each other is not always feasible or productive. Depending on the project type and personalities involved, there might be a need for people in between.

Regardless, the second step must be to determine the possible changes the customer is not likely to consider. This usual involves technical issues, such as user interface considerations or development time. While these should be brought to the attention of the customer, they might still request that their approach be implemented. Therefore, the implementation should be designed to easily accommodate both the customer’s expected changes and your expected changes.

---