> Over-engineering is an attempt to predict the future, while quality-engineering is maximizing extensibility. That's not really over-engineering, but rather b

> Over-engineering is an attempt to predict the future, while quality-engineering is maximizing extensibility. That's not really over-engineering, but rather building incorrect abstractions or building at the wrong abstraction level. In other words, it becomes over-engineering because a lot of effort is spent on an incorrect abstraction that is not general or flexible enough. That said, if you don't have time for a proper abstraction, then it is better to do as suggested and keep things as simple as possible, however that also has its downsides because it often leads to re-doing the work once you find out about more requirements. Good abstractions don't require predicting the future, they require "covering" the feature space in such a way that small changes to the "moving parts" will drastically change the behavior of the feature. So it's about creating a solution that is flexible and also powerful, with the trade-off being the transparency of the implementation, which might be difficult for junior engineers and/or managers to understand. I think when done right, you spend a little more time upfront designing but end up with a resilient, flexible, and powerful solution that can pivot quickly for the customer. Unfortunately, and also understandably, this is not a favorable approach in many companies because it is hard to manage and estimate properly.