When life gives you lemons

...make lemonade

A project gone bad

There is far less hype than there used to be but too many people mistakenly thought that OO was synonymous with good. My experience is that OO is better all things being equal but in real life all things are not equal.

In my experience with student software engineering projects the best students produced OO designs that were about twice as complex as they needed to be and the average was about three times as complex. The typical problem was relying on the class hierarchy to make all the important distinctions rather than using attributes.

For example in risk there is a deck of cards with one of three symbols (cannon, soldier, calvary). Almost every team modeled this with a class RiskCard having three subclasses CannonCard, SoldierCard and CalvaryCard. This was totally unecessary but it was praised by the person handling the design phase because it was more OO (ironically she also had a background in Smalltalk). One class was not only sufficient --it was far simpler and from an engineering standpoint was to only reasonable solution.

Another problem was adding unecessary flexibility. One team implemented the map in such a way that each continent was a class and you could add a new continent by adding another subclass. There was nothing wrong with how they solved the problem other than the fact that it didn't need to be solved.

My experience with OO projects from industry usually involved the opposite problem. They don't use the OO facilities in situations where they offer clear advantages. If they are writing high quality code then this isn't too bad; in fact it is far better than writing really bad OO code. Some people suggested that a "pure" OO language should be used to force them to write OO code but in my experience this is the path to failure.

Ultimately, it is about the expertise of the people you have available. If you have the necessary expertise in analysis and design then, in my opinion, OO is the way to go. If you don't then either you need to get it or make do with what you have. Often making do with what you have is the right decision from an engineering point of view.