5 ms·

The terms "over-engineering" is so ill defined as to be mostly useless. I have a strong personal opinion of when things become over-engineered, but that means

The terms "over-engineering" is so ill defined as to be mostly useless. I have a strong personal opinion of when things become over-engineered, but that means little. I've worked for smaller companies, which tend to under-engineer due to time restraints. And I've worked for large corporations with such overkill process that it is amazing anything gets shipped ever. And yet it does, it takes almost forever, and costs far more than it should, but it does eventually ship. Discussing "over-engineering" may be fine for general interest communities. But I think on HN we should aim higher. I'd love to have a rigorous discussion on how we can identify designs as either over or under engineered.

davedx 14y ago
Some parts are not really that ill-defined. e.g. an interface with a single implementation is code-smell. That's a pretty good start.
- Drbble 14y ago
  "smell" is ill-defined!
nicalsilva 14y ago
Sure! This post is like an invitation to discuss the subject, right? "over-engineering" was not the point anyway. The title is a lie. The point was: dont be afraid of making mistakes (Over-engineering and the likes) when you can afford to, so you can learn from them and aim at high quality discussions on HN.
- srbravo1 14y ago
  well said
cliffbean 14y ago
When I discovered the phrase "Speculative Generality" in Fowler's Refactoring book I suddenly realized there was a name for a problem I already knew I had. This is one specific kind of over-engineering which we can identify -- when creating an abstraction, are you doing so in anticipation of an actual need, or merely of an imagined need? Another kind of over-engineering is speculative optimization (often called "Premature Optimization", but I like to emphasize the speculative nature of it, because that's the heart of the issue). Am I working to make the system faster in response to actual evidence of a performance problem, or am I just guessing about performance? Over-engineering isn't always bad. It's all about predicting the future and weighing risks, with everything that entails. It's hard, but it's a fundamental part of design, and of life. Whenever I'm unsure about whether a particular speculative generality or optimization is justified, I try to step back and find implicit assumptions. I try to turn "This might help some day" into "I'll need this if XYZ happens". If I can't do that, it's a bad sign. And I agree with the original author's point: making mistakes in places where you can afford to fail, or where you can afford to recover, is a great way to learn.

davedx 14y ago

Some parts are not really that ill-defined. e.g. an interface with a single implementation is code-smell. That's a pretty good start.

Drbble 14y ago
"smell" is ill-defined!

nicalsilva 14y ago

Sure! This post is like an invitation to discuss the subject, right? "over-engineering" was not the point anyway. The title is a lie. The point was: dont be afraid of making mistakes (Over-engineering and the likes) when you can afford to, so you can learn from them and aim at high quality discussions on HN.

srbravo1 14y ago
well said

cliffbean 14y ago

When I discovered the phrase "Speculative Generality" in Fowler's Refactoring book I suddenly realized there was a name for a problem I already knew I had. This is one specific kind of over-engineering which we can identify -- when creating an abstraction, are you doing so in anticipation of an actual need, or merely of an imagined need? Another kind of over-engineering is speculative optimization (often called "Premature Optimization", but I like to emphasize the speculative nature of it, because that's the heart of the issue). Am I working to make the system faster in response to actual evidence of a performance problem, or am I just guessing about performance? Over-engineering isn't always bad. It's all about predicting the future and weighing risks, with everything that entails. It's hard, but it's a fundamental part of design, and of life. Whenever I'm unsure about whether a particular speculative generality or optimization is justified, I try to step back and find implicit assumptions. I try to turn "This might help some day" into "I'll need this if XYZ happens". If I can't do that, it's a bad sign. And I agree with the original author's point: making mistakes in places where you can afford to fail, or where you can afford to recover, is a great way to learn.