I imagine a spectrum that goes from under-engineering(0) to right-engineering(5) to over-engineering(10), and I imagine the same situation falls on different parts of that line for different people!<p>So I want to know how you determine what 'right-engineering' is, and how you cope with co-existing with under-engineers and over-engineers on your team.<p>Thanks!
To my mind, over-engineered means "designed to solve problems that it won't actually need to solve". Under-engineered means "<i>not</i> designed to solve problems that it will actually need to solve". So it comes down to an accurate assessment of what problems the system/program will have to solve.<p>The next question is, "What is your time frame"? (Dwolb already said this.) Is this system going to need to continue to work for a week, or for 30 years? You're not going to be able to predict all the problems you'll face in 30 years, so if that's your time frame, you need to design something that's flexible enough to be (somewhat) easily changed to handle the unexpected.<p>The next question is, "What are the consequences of failure?" You over-engineer software that flies in the space shuttle, because if the unexpected happens, your software has to continue to work, or people die. At that point, it's not over-engineering - it's necessary and appropriate. But it would be over-engineering to write software to the same standards, when the software is running a web page.
I've never seen this clearly defined. At the root, criteria for engineering come from the intended uses. If the product is meant to last for 5 years and you design the product for 50 years, you've probably over engineered. If the product is meant to last for 5 years and you've designed for 6 years, you MAY have under engineered, given a statistical variance for failures over time (e.g too many failures happen at 4 years instead of 6)<p>So, an academic answer, it depends :)
There is no over and under engineering in software development. Can the software be written in a simpler way? If yes then it is not "right-engineered." If no, then it is. Writing software is more similar to mathematical proofs (ask yourself, how do you know when your proof is done?) than bridge building.