To Over-Engineer is Human

The title is a play off of a book named To Engineer is Human and it seems especially true among software developers.

As an example of over-engineering, imagine a civil engineer, who needing to build a bridge, builds a bridge-building machine, and then being unsatisfied that the bridge-building machine can only build one type of bridge, then sets out to build a bridge-building machine generator (i.e. a machine that produces bridge-building machines).

I did that recently; not the bridge builder, but the software equivalent.

I’ve been working on a user interface prototype for my stock screening application. Since it’s a web-app, the UI (i.e. user interface) code is all in JavaScript. JavaScript doesn’t have a traditional class system like other object-oriented languages, so I set out to build one.

I built one that was built upon another JavaScript library called ExtJS. The system worked, but I wasn’t satisfied because my class system wasn’t as simple to use as the class system that John Resig recently released. So, I’ve been thinking and experimenting with different ways of building class systems, because I don’t want just any old class system, I want the easiest, fastest, smallest, best JavaScript class system.

What I came up with is hideously complex and it took me hours to code and debug.

Fast-forward to yesterday. Google released a javascript library that looks very nice, is simple to use, is very well documented, and is proven (on properties such as gmail.com, Google Calendar, and other google apps). So I  think I’m going to scrap the complex class system and instead go back to something more JavaScript-esque, and simple to use, and use it along with Google’s javascript library.

Hopefully I can keep from over-engineering this thing again. I’m going for simplicity and minimalism this time.