Those of us in a complicated world

Why are we obsessed with overengineered solutions? It wasn’t long ago that I caught myself deleting a chunk of source code in SVN. As a reminder, I’d almost tattoo the acronym KISS (keep it simple and stupid) on my right forearm. Preferably in Chinese, so if it came to it I could say it was part of the menu from the Chinese buffet around the corner and blame it on youthful foolishness. Who can honestly say they’ve never overengineered anything?

We overengineer when we use technologies and practices and create abstractions that get in our way in the short term and don’t deliver what we expected in the long term.

I needed a data store for one project, basically a hierarchy of XML documents plus metadata. I spent nearly two weeks implementing it. Naturally, it also needed a user interface to manage the data. As often happens, a small change in the requirements and some practical experience shredded my idea that it was nearly done. After wrestling with myself for several hours, I weighed the pros and cons and deleted the existing code so it would stop taunting me. In about two days I implemented and tested the same functionality on an ordinary filesystem. Directories give us the hierarchy, file naming and extension conventions replace some metadata, and the remaining metadata lives in ordinary XML documents. Any file manager can serve as the user interface. Any version control tool (SVN, CVS and so on) can handle retention and versioning.

What did I learn? Sometimes you have to take a step back before you can take two forward. I don’t know why we keep overengineering. Maybe the solutions are more exciting while they’re still in our heads. Maybe we’re convinced they aren’t really all that complicated. Maybe we don’t believe 80 percent is a lot, so we sacrifice it for the other 20 percent. Sometimes we dream up architectural constraints to protect ourselves from nuclear catastrophe when the worst we face is a light May Day shower. Either way, KISS.