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.
Thanks!
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.
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.
It's "be prepare now" vs "fix it later". "Preventative" vs. "reactionary"
I was working on a project where it was pointed out that our code could be written in a simpler way. It would take up less CPU cycles and, more importantly, use half as much storage.
The optimization proposed: stop the background script that makes backups of the data.
It's absolutely true that not having that script running in the background would use less computing resources and lead to a simpler program, as well as saving nearly a terabyte of disc space. However, I don't suspect that you would ever recommend performing that simplification.
So, an academic answer, it depends :)
They don't always feel the same. They want me to engineer less, and I just can't do it. It feels like I'm doing a huge disservice to the product, to future me (developing more features), and to them.
Engineering:
[under(0) -> right(5) -> over(10)]
