How To Prevent Overengineering?
Startup Codex

I really like the common sense contained in this short post about the risk of overengineering.

We've all gone through it, or are about to go through it (again): building something that, in hindsight, could have been done in a much simpler way.

Mark Snyder shares with us a two-step good practice to apply preventively when development is still in its technical design phase: identify the elements that really create value and raise a specific series of questions for each of them (detailed in his post).

The objective is to generate healthy discussions and more optimal development.

We all do it. I’ve looked back at something that took me weeks to build and said to myself, “Wow that could have been far more simple.”

I blame it on brain “modes”. When we put our brain into solutioning mode — we forget the problem and begin constructing a solution we can take pride in. I suspect it has something to do with creativity. It’s not limited to software development either — I credit overengineering for that really complex change management process or that 200 page employee handbook you may have been asked to read.