I’m not sure I’m sure where to go with with this week’s blog battle, Engineering Over/Under. But, a deal is a deal, and I’m still posting more than Moseng! By the way, this post has no answers, just some ravings.
I participated in the Science Olympiad when I was in high school. I did well in two competitions, orienteering and clock building. The other task I had but didn’t do so well in was bridge/tower building. I’m sure my bridge would have been the most efficient, but for safety reasons there was a limit to how much weight they would put on my bridge. The bridge was over engineered. In order to win, you need the most efficient bridge that will fail. If it stands, there were inefficiencies in the system.
There isn’t much to that story that has to do with software. Over engineering is about costing too much for the job at hand.
The truth is what we call over engineering in software is about picking the wrong things to build. It isn’t over engineering to put a ferris wheel on a bridge, it’s just wrong. But to build N-tier web services when all you need it to catch responses from an employee survey? We call that over engineering for some reason. No one complains if you make it too fast. But these additions to our software take more time and money and often make your software worse.
So what do we do about this? Focus on what you really need to build. Try not to get caught up with arbitrary requirements about how this needs to be web-scale or have zero latency. Now, the trick is balance. These are valid concerns that may be important, so you can’t paint yourself in to a corner where you can’t easily address them in the future.
Wait, what? Not make it right the first time? When architecting a real building, it is possible to design a building with rooms and features so specific to a certain layout that you can only use those spaces in specific ways. The obvious examples are bathrooms and kitchens (I’ve been thinking about a remodel for a few years), but auditoriums are also problems. The real treasure in building architecture is making flexible spaces that can be used for many purposes and occasions. Have you ever really looked at a great museum’s architecture? The galleries can usually be reconfigured in very short order to accommodate new collections or events.
In software, we like to try to keep our business logic free of our persistence or display technologies, just like rows of theater seats and a stage make it hard to repurpose a room. Some times the Smart Forms pattern is actually the answer. And sometimes it may be okay to do a little work in the UI thread.