Warp wrote:

>   Overengineering (or in the case of software, overdesigning) really can be
> a real problem.
> 
>   I have encountered this problem myself in a project I was working.
> One guy was really too infatuated with object-oriented design, and went
> really overboard with it. Almost *everything* had to be its own separate
> class, in a really complex inheritance hierarchy, with several layers of
> abstractions, one on top of another. One program he made consisted of over
> 20 source code files and was rather long and really complicated. The
> program source code was rather hard to understand.
> 
>   Years later I had to reimplement that same functionality from scratch
> (basically it was a simple modification of a similar tool). My version
> of the same program consisted of 3 source code files, and the program
> was 10 times faster with all inputs I tried. The OOD was, IMO, still
> pretty good, but much more understandable because of a way more simplistic
> approach.

I think if you're actually *trying* to do something that's inherantly 
complicated, a complex design may be called for. (And especially if 
future requirements aren't completely certain.)

OTOH, unless you're psychic, you will never know what the future holds, 
and any flexibility you design in will probably turn out to be not quite 
the right thing for what you *really* end up trying to add. There is 
definitely a lot to be said for keeping a design as simple as feasible!

Ever heard the phrase "analysis paralysis"? ;-)

Post a reply to this message