
How do you determine where the lines between under and over engineering are? - jpmcglone
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 &#x27;right-engineering&#x27; is, and how you cope with co-existing with under-engineers and over-engineers on your team.<p>Thanks!
======
AnimalMuppet
To my mind, over-engineered means "designed to solve problems that it won't
actually need to solve". Under-engineered means " _not_ 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.

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.

~~~
jpmcglone
I guess I treat the frameworks and tools of the products I'm building like
software that flies space shuttles. In my mind, even as the product changes
and evolves, I will have built tools and framework that makes changing the
software easy and less scary. Moving a tooltip or changing text, or supporting
localization should not be risky, imo, but I have to fight for building out
things like that.

It's "be prepare now" vs "fix it later". "Preventative" vs. "reactionary"

~~~
AnimalMuppet
But making it easy to move a tooltip or change text are not over-engineering.
In fact, it would be irresponsible to _not_ prepare for that kind of change.
But you don't engineer that kind of software to 99.9999999% reliability, which
is the kind of thing I meant by "space shuttle software".

~~~
jpmcglone
Thanks.

------
Dwolb
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)

So, an academic answer, it depends :)

~~~
jpmcglone
Yea, I was looking for subjective or (seemingly) objective answers :) Whatever
you got!

------
loumf
I judge it by how amenable the code-base is to the kinds of changes I need to
make over time. Over and Under resist common changes in different ways.

~~~
jpmcglone
I agree. So I'm working with a team where I engineer more than they do. We
both feel we "right-engineer", so to them I'm over-engineering and to me
they're under engineering. I think we could co-exist. I build the frameworks
and design clean interfaces for them, that way their feature stack is shorter
and quicker to get out.

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.

------
bjourne
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.

~~~
rprospero
I'm guessing that the reason that you've been downvoted is because sometimes
the simpler program isn't "right-engineered".

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.

------
jpmcglone
__For the visual folk __

Engineering:

[under(0) -> right(5) -> over(10)]

