In the cases I've encountered it, the term over-engineering in the context of software development is more often used to refer to building in allowances for fut

In the cases I've encountered it, the term over-engineering in the context of software development is more often used to refer to building in allowances for future functionality rather than for making the software more robust. Although I have seen the latter as well - for example massively increasing the complexity of some part of a distributed system to eke out a theoretical eight 9 of availability. The concept of over-engineering has been co-opted more recently by Agile zealots as a major bogeyman to the point where I've seen people trot it out to argue against structuring code to account for needs that are several weeks out because "It's not in THIS sprint! YAGNI!", with the predictable result that several weeks later it creates more work to restructure the code and when invariably there isn't time for that, leaves a worse architecture in the long-run as the needed functionality is bolted on.