Hacker News Reader

Comment by feoren | Hacker News Reader

It's a weird term, "over engineering". Think about over-engineering a bridge. What does it look like? Huge and bulky, way too expensive, able to hold much more weight than it should, lots of walkways and access points and design features that nobody really wants? But wait: "any fool can build a bridge that doesn't fall down. It takes an engineer to build a bridge that just barely doesn't fall down." The whole point of engineering is to figure out exactly what the bridge needs to do and make it do only that. So the "over-engineered" bridge is actually under-engineered -- they haven't thought enough about the actual problem. So too is most code that is called "over-engineered" -- it's far more common that people haven't though enough about the problem than that they've over-thought it.

View on HN

When I say "over-engineering" I mean stuff like this: https://github.com/MarkSFrancis/enterprise-fizz-buzz Building a whole ton of stuff, just to do something fairly trivial.

In this example, it's black and white obviously over engineered. The reality is, in an application of moderate complexity, whether or not it is indeed over-engineered is a far more subjective calculation.

E.g., >90% of engineers would agree enterprise-fizz-buzz is over-engineered.

But perhaps ~50% of engineers agree my SaaS app is over-engineered.

Just to be very clear, that application is intended as a joke. (just in case)

> he whole point of engineering is to figure out exactly what the bridge needs to do and make it do only that. So the "over-engineered" bridge is actually under-engineered -- they haven't thought enough about the actual problem. So too is most code that is called "over-engineered" -- it's far more common that people haven't though enough about the problem than that they've over-thought it.

It is different in the physical world where materials are a big factor and engineering will definitely not make free use of them. There are inefficiencies here and there but they're largely reduced. In the digital world of programming accidental and intentional complexity often slips through without anybody noticing and that is for many reasons. It's a relatively new field and is still quite inefficient. I worked in many places whose codebases are a giant maze designed with no clear architecture and sometimes I suspect this complicated mess of intentional moat building engineering.

I think that in a way that view is like the entry level engineer's lie. It makes it seem like the engineer is there to make shoddy things, always a hair's breadth from failing.

What an engineer is actually there for is to run the numbers and predict behavior without having to go through the mess or expense of doing it any more than absolutely necessary. To plum the depths of our collective technical knowhow to drive a project that makes all the right tradeoffs.

It's not about making a bridge that can hold a semi out of matchsticks and bubblegum. It's about knowing it won't work without having to do it to find out.

I like to call it "poor engineering" and there are many forms of poor engineering I've seen. Following the analogy... painting the bottom of the bridge in same color as the terrain. Then repainting because there were color differences.

Spending time and money looking for lighter materials even when the bridge is designed to support a lot more weight than traditional time tested materials. Justification : "Maybe cars will get heavier, and bigger saving 3 pounds is a good pursuit"

But people will hate your suckless bridge and instead will use a more feature rich bridge with more bells and whistles. https://stroustrup.com/P0977-remember-the-vasa.pdf

Reply on news.ycombinator.com