I’ve been coming back to this in my mind for the past few days, may as well have it be my first real post. In the field of computer science, in particular software design and implementation, there seem to be two different, parallel approaches: the theoretical and the practical. The theoretical approach (as is the case with most problems solved in theory only) usually fails to take into account deadlines, mental fatigue, and laziness. The practical approach on the other hand ignores the theoretical because of this failure. There are instances where these two sides meet, but they are few and far between. Let’s take a look at why.

According to object oriented design principles, a developer should strive to encapsulate every piece of reusable logic to avoid duplicate implementation at all costs. So, theoretically any piece of reusable code should be in one spot and a call made to that spot whenever necessary. With simple scenarios this is a no-brainer. But complicated scenarios can become murky, and may require a great deal of forethought before the coding commences. But (here is the but in this illustration) the current assignment (yes we now have an assignment) is to make a change in only one area, involving a business object that descends from an ancestor infra-structure object - and there is one day to do it.

We’ll assume that the implementation is slightly involved. At first glance there isn’t any reason to put this process in a common place; it only involves one object and one process. The work is done, tested, and things are good. However, (here is where we enjoy the benefit of both foresight and hindsight simultaneously), a month later four other programmers need very similar functionality in four other places. A quick search through source for precedence yields the new code, so they copy it, modify it slightly, and call it a day.

The first dilemma: Code in multiple places. Is there a fault, who is at fault and why? Should the first developer have been able to foresee the need for this functionality in other places and make changes accordingly? Should the next developer who copied it have moved it to the infra instead? Does it really matter?

The second dilemma: Functionality needs to be modified. A month later a bug comes in regarding the new functionality. Someone is going to have to make changes in multiple places. Either over time or maybe it isn’t even known that code exists in multiple places so it’s fixed once. Then another bug from another area comes in, same problem. So it’s fixed twice… etc…

Regardless of how these scenarios play out, it is clear much of the ensuing problems could have been avoided from the get-go if the initial work was done generically in a generic place. But seeing as it wasn’t, the problems could also have been lessened at any step if the process was modified to be more generic and moved to a generic place instead of being copied.

The next few posts will attempt to outline why this was not done, and delve into the reasons for theory vs. practice.