4 ms·

I have quite strong feelings on the subject of over-engineering. I've had to argue against over-engineering many times in my career. I wasn't about discouragin

by akamaka 11y ago

I have quite strong feelings on the subject of over-engineering. I've had to argue against over-engineering many times in my career. I wasn't about discouraging thinking. I was fighting against actually implementing specific features that attempted to solve poorly-defined problems whose details had not yet come into focus. Developing those features would significantly impair other parts of the project. For example, the problem might be "What if our database becomes overloaded one day?" Choosing to implement, say, sharding, could lead to an over-engineered system which gets in the way of solving the many different future performance problems that could crop up. I think it's quite reasonable to use the term "over-engineering" in this sort of situation.

tyre 11y ago
I definitely agree that over-engineering is a problem. My feedback was meant to be about how to communicate that balance. In your example, if you tell the other person that their database sharding is over-engineering, they can say one of two things: a) No it isn't. b) Yes it is and I think over-engineering is a good thing. I have never heard someone say (b); if they thought it was over-engineering then they wouldn't have advocated for it. The negative quality is part of the definition. What you're likely disagreeing on is how far in the future you're team should be thinking or how much data is necessary to make a confident decision. I don't think it was your intent to stop long-term thinking, but if someone says "we shouldn't over-engineering things", I don't think that solves any ambiguity because no one was intentionally over-engineering before. It's akin to saying "don't do bad things." People never do bad things, only things that are bad under a different set of principles or based on other values. My feedback is that this document should define what over-engineering means in their context (since it, like what is "bad", is context-specific) and lay out what engineers should look out for.
- yetanotherjosh 11y ago
  If you agree it's a problem, I'm not sure why you think it shouldn't be talked about. Your (a) and (b) responses would come from an engineer who is not open to dialog, and I'd say from an engineer I'd prefer not to work with. I would add another option to your set of possible responses: (c) Let me now think harder about whether we really need database sharding and justify why I think it's needed, and allow this further analysis to possibly lead to a revised, simpler design. That's the route that the open-minded, discursive engineer will take.
  - darkerside 11y ago
    I think the problem with a loaded term like "over-engineering" is that you are assuming they haven't fully through their idea through, and that's why they don't see things your way. I've seen much better results come from explaining why you think database sharding isn't necessary yet (even if you think the reasons seem obvious), and then asking your colleague to help you understand what you might be missing.
    - yetanotherjosh 11y ago
      That's a reasonable perspective but the assumption I would be making isn't that they haven't thought it through, it's that they're using a higher bar for what's necessary, and are thinking it through from that point instead. The dialog is then about coming to a shared understanding of what the actual requirements really are. Therefore it's not critical or something to be taken personally about one's proposed implementation, it's the symptom of unclear requirements and the need to clarify them.
      - kybernetikos 11y ago
        > Therefore it's not critical or something to be taken personally about one's proposed implementation, it's the symptom of unclear requirements and the need to clarify them. Absolutely, and that's why I agree that the term Overengineering is an unhelpful shorthand that implies criticism to an unnecessary extent.
- akamaka 11y ago
  Thanks for explaining, I see what you mean now!

by akamaka 11y ago

tyre 11y ago

I definitely agree that over-engineering is a problem. My feedback was meant to be about how to communicate that balance. In your example, if you tell the other person that their database sharding is over-engineering, they can say one of two things: a) No it isn't. b) Yes it is and I think over-engineering is a good thing. I have never heard someone say (b); if they thought it was over-engineering then they wouldn't have advocated for it. The negative quality is part of the definition. What you're likely disagreeing on is how far in the future you're team should be thinking or how much data is necessary to make a confident decision. I don't think it was your intent to stop long-term thinking, but if someone says "we shouldn't over-engineering things", I don't think that solves any ambiguity because no one was intentionally over-engineering before. It's akin to saying "don't do bad things." People never do bad things, only things that are bad under a different set of principles or based on other values. My feedback is that this document should define what over-engineering means in their context (since it, like what is "bad", is context-specific) and lay out what engineers should look out for.

yetanotherjosh 11y ago
If you agree it's a problem, I'm not sure why you think it shouldn't be talked about. Your (a) and (b) responses would come from an engineer who is not open to dialog, and I'd say from an engineer I'd prefer not to work with. I would add another option to your set of possible responses: (c) Let me now think harder about whether we really need database sharding and justify why I think it's needed, and allow this further analysis to possibly lead to a revised, simpler design. That's the route that the open-minded, discursive engineer will take.
- darkerside 11y ago
  I think the problem with a loaded term like "over-engineering" is that you are assuming they haven't fully through their idea through, and that's why they don't see things your way. I've seen much better results come from explaining why you think database sharding isn't necessary yet (even if you think the reasons seem obvious), and then asking your colleague to help you understand what you might be missing.
  - yetanotherjosh 11y ago
    That's a reasonable perspective but the assumption I would be making isn't that they haven't thought it through, it's that they're using a higher bar for what's necessary, and are thinking it through from that point instead. The dialog is then about coming to a shared understanding of what the actual requirements really are. Therefore it's not critical or something to be taken personally about one's proposed implementation, it's the symptom of unclear requirements and the need to clarify them.
    - kybernetikos 11y ago
      > Therefore it's not critical or something to be taken personally about one's proposed implementation, it's the symptom of unclear requirements and the need to clarify them. Absolutely, and that's why I agree that the term Overengineering is an unhelpful shorthand that implies criticism to an unnecessary extent.
akamaka 11y ago
Thanks for explaining, I see what you mean now!