[kenver]

This made me think about how we use the term 'over engineered' in our industry. In most industries it seems to be a good thing (i.e. space shuttle). In our industry it's synonymous with bad, unnecessarily complex code. We seem to have a knack of taking positive attributes such as clever, and flipping them!

[kergonath]

> In most industries it seems to be a good thing (i.e. space shuttle)

It really isn’t the case in most industries. There are a couple of industries with inherent complexity and where the cost of failure justifies some kind of over-engineering (you could add particle accelerators, medical imagery devices, aircrafts, and things like that). In these cases, you throw a lot of money and very good engineers at the problem. Most industries are not willing to do that, because dit is expensive. So they produce unreliable crap that breaks all the time.

In the vast majority of cases, over engineering means more parts that can fail in more “interesting” ways, and that are more difficult to diagnose because the thing is more complex than it needs to be. “Over-engineered” is really not a compliment applied to a car or a house, for example.

Engineers are not gods. Sometimes they are stupid just like any other human. They also need to stay humble and recognise that a system needs to be as complex as needed to fulfil its purpose, but not more.

> We seem to have a knack of taking positive attributes such as clever, and flipping them!

“Clever” is a compliment. But you can have too much of a good thing, as in “too clever by half”. If you depend on something, you don’t want it to be clever, you want it to be reliable first.

[eutectic]

I would say that the space shuttle is the perfect example of the risks of over-engineering.

[AstralStorm]

It's not. Space shuttle was pretty well engineered to do the things it was meant to. (If anything, launcher and ops were underengineered hence the failures.)

The problem was that it was meant to do too many things at the same time. Some of them were: being able to return to US territory from anywhere. (Hence semi-aerodynamic.) Carrying people and a lot of cargo. (Hence big.) Deploying any kind of cargo rather than defined operations. (Hence Canadaarm.) Being reusable. (but not the launcher...) Etc.

The chief problem of it is that it was first in a class research vehicle. And you cannot refactor rockets. (At least not cheaply. Prove me wrong Starship.)

[dgb23]

It’s not exclusively used for clever code.

I think a more common case for the term is to describe a program/system that covers way more ground than it needs to in terms of abstraction, tooling, features, scalability and performance.

Example: I handed off a website a year ago that didn’t have any sort of remarkable engineering/usage requirements on the backend side. Internal operations of our client however insisted on deploying it on a kube cluster, so we had to accommodate for that. All they actually needed was maybe some caching, if at all.

Mild case, but I think of these types of stories when thinking of “over engineering”.