HN Explorer

How do you determine where the lines between under and over engineering are?

4 points by jpmcglone ↗ HN
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!

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!

12 comments

[ 3.6 ms ] story [ 39.0 ms ] thread
jpmcglone
For the visual folk

Engineering:

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

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!
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.
jpmcglone
Fair point. Your focus seems to be on product. What about frameworks?
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.

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.

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