4 ms·
Many of these guidelines essentially boil down to strategies for preventing over-engineering. I concur; in my experience, premature optimization is one of the
by gfiorav 3y ago
Many of these guidelines essentially boil down to strategies for preventing over-engineering.
I concur; in my experience, premature optimization is one of the most expensive pitfalls. This primarily stems from the fact that circumventing potential issues too early leaves them unchallenged, resulting in the next team having to devise expensive solutions to address the unnecessary complexity.
The approach that was instilled in me is this: optimizations rely on presumptions, and these presumptions are often incorrect in the beginning.
Additionally, I've discovered that managing ego and understanding psychology play crucial roles in dissuading individuals from creating overly complex code.
- vrosas 3y agoI like to say, “solve problems you have, not problems you think you have.”
- deleted 3y ago[deleted]
- arethuza 3y agoYAGNI: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
- vrosas 3y agoSort of, but people get defensive and start to argue that they _will_ need whatever it is at some point. But my argument is that, fine, you may be right, but if it's not needed _right at this very moment_ there's no reason to rush it in. Often the best way to prepare for the future is to do as little as possible - keeping things simple now makes adaptions much easier down the road if and when the need actually arises.
- deleted 3y ago[deleted]
- digbybk 3y agoOur future selves will always have more information than our present selves, so we should let them make the decision whenever possible.
- kvmet 3y agoThis concept is also in-line with Lean/Six-Stuff and identifying "wastes". Overproduction (analogous to over-engineering) is usually considered the worst type of waste because not only are you making something you don't need, you're spending effort that could have been used on something that you _do_ need.
- goto11 3y agoAnd digging a step deeper: Over-engineering often happen because you think you might need the complexity later, but it will be more difficult or risky to extend the system at a later time. E.g. starting out with a microservice architecture even though you only have 100 users, because you think it will be too difficult to re-architect a monolith the day you hit a million user. So you should address why it feels like the code becomes less malleable over time.
- m463 3y agoSomeone I know said - don't get fancy with errors. fail early and simply.