Symptoms

---

Overly simple code is more difficult to identify that the overly complex code created by Complexification. This is true in part because complex code should be less common and therefore easier to analyze than simple code. Since the majority of the code on a project should be simpler code, it becomes hard to identify the overly simple code from the correct level of simplicity. On the other hand, complex code tends to stick out and requires only an inspection to mark it as a candidate for being overly complex. So, what are the symptoms that we can use to help reveal overly simple code?

So Simple It Does Not Do Anything

The reason we write code is to accomplish some goal, or at least it should be. However, due to poor coding practices or the inevitable degradation of code over the course of a project, sections of code can cease to perform any useful function. Spotting this type of code serves two purposes. First, it improves performance by removing code that does not need to be called. Second, and more important, it makes the code more readable and maintainable.

What does this have to do with overly simple code? After all, you would not think of extra code coming from simplicity. To understand this, it is best to understand that simplicity does not always mean code simplicity. Simplicity can also mean design simplicity. While seeking design simplicity, it is easy to increase code complexity.

The creation of interfaces and class hierarchies is a common place for this to occur. In the interests of creating consistency in design and use of interfaces and objects, the programmer might be required to introduce code simply to handle the odd cases created by attempts to make all objects equal when they are not. This is generally caused by a misunderstanding of object-oriented technology. Although the design at first appears simple, in practice it becomes more complex and forces the addition of functionality just to maintain the simplicity of the design.

Shifting Complexity

Most applications contain layers of functionality built on top of each other. In a properly designed application, these layers should distribute the complexity as evenly as possible. By assigning the appropriate responsibilities to the appropriate layer, the implementation can be simplified while maintaining a simple interface to the other layers. However, if responsibilities are assigned to the wrong layers, the overall complexity of the code will rise.

One of the most common occurrences of this is Over Simplification in the lower-level functionality of the application. In an attempt to provide a simple base on which to build, the complexity is shifted upward where it becomes many times more complex to implement. This rise in complexity is caused by the differences in data access and the increased communication necessary between layers. This simplification is often accompanied by weakening of encapsulation and abstraction to allow the transfer of functionality to another location in the code. Whether this occurs through design failures or the natural evolution of the code, it is a sign of Over Simplification that should be corrected.

Simply Disastrous

One project developed a very simple interface that was to handle the majority of the work for the application. It consisted of two main classes, and only one of these classes was designed for inheritance. Let us look at the basics of these two classes:

   class t_Object {       // ...    private:       // Linked list of object properties.       t_Property *m_properties;    };    class t_Property {       // ...    private:       // Type identifier.       int m_id;       // Owner object.       t_Object *m_owner;       // Next property.       t_Property *m_next;    };

Every instance of the main object would be the same except for the properties that were attached to it. Each property knew only about itself and its owning object. This design was chosen for its simplicity and consistency. In addition, several manager classes handled the execution of specific types of properties.

This simple system quickly broke down as it became obvious that properties were required to know about each other. Because the only way to distinguish the property was through its type, the code became scattered with small cut-and-paste instances of linked list searches for a particular property type. These were accompanied by type cast, introducing even more chances for error. Numerous bugs were encountered because of this originally simple design.

Do Not Touch

One roadblock to fixing Over Simplification can often be a sign of a programmer suffering from that very illness. Because there is a beauty in simplicity, a programmer who creates a simple design and implementation might defend that implementation even if the change will result in increased simplicity for the code as a whole. This narrow vision is understandable from several perspectives. The time invested in writing the code and creating the simple design seems in danger, and modification to it will make the original programmer’s job of maintaining it more difficult.

Nevertheless, these views ignore the necessary give and take required for a team to function efficiently. Making the changes will help in relations and also show a willingness to share in responsibility for the entire application. When you find yourself or another programmer resisting changes to functionality because of a fear of breaking the simplicity, step back and evaluate how the change will affect the simplicity of the code base as a whole. If you end up with a simple low-level implementation, but a horrible mess at the middle level and up, you will regret not moving some of the responsibilities down to the lower level.

---