4 ms·
What you describe is not really over-engineering, at least not according to the definitions he quotes. I would just call it bad engineering instead.
by rejschaap 10y ago
What you describe is not really over-engineering, at least not according to the definitions he quotes. I would just call it bad engineering instead.
- knocte 10y agoThing is, in my book, bad engineers are the ones that cannot get anything done (or barely do) because they are not talented/intelligent enough. These are harmless. But what about the ones that get things done (at least their managers perceive so) but creating these enormous turds? They think they have a clue, but are just barely starting to scratch the surface, and they can harm any project a lot. For me, overengineering is not excessive optimization or quality, but excessive unnecessary complexity (when there could be an alternative, much simpler, implementation, which still complies with the requirements imposed).
- xg15 10y ago> For me, overengineering is [...] excessive unnecessary complexity (when there could be an alternative, much simpler, implementation, which still complies with the requirements imposed). I think the article relates to that though. I agree there are cases in which the complexity of objectively uneeded and will never be useful. (Reinventing the wheel, bad design, the aforementioned misapplied OOP principles and unit boundaries) but what the article stresses IMO is that it's not always easy to see if the simple implementation will comply with the requirements in the future as well. Some complexity could be justified if the speculation on the future is backed by facts.