3 ms·

I'm trying to think of examples of overengineering in software and am having trouble from my own experience and extensive reading. I can think of languages lik

by kev009 10y ago

I'm trying to think of examples of overengineering in software and am having trouble from my own experience and extensive reading. I can think of languages like C++ that facilitate what I would use a more derogatory term for like autoerotica. The site's example, taking Javascript seriously, almost always falls into this category. In something like an automobile, using boxed steel everywhere would make the thing sturdy as hell at the expense of fuel economy and less objective things like aesthetics. A bridge design might be too expensive, or a material too heavy to facilitate the architectural vision. Etc. In software this term is used where the software is actually under-engineered, like a shoddy deployment without any consideration of consequences. Technology like a message queue or distributed database are the victims of poor understanding or oversold claim. Almost always the real problem is clueless management and a symptom of fad driven architecture. So going back to the materials example.. What software wouldn't benefit from end to end back pressure? Circuit breaker fault management? Memory safety? Formal proof? None of these things should have any bearing on the user, and there are a lot of companies could afford to figure out how to make one or more of these things have minimal effect on front side of SDLC with very positive effects on the long tail. Software is almost to fluid and inexpensive to be over-engineered.

skookum 10y ago
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.
- dasil003 10y ago
  The trouble with Ya Ain't Gonna Need It is that its counterpart You Are Gonna Need It has the same acronym.
- adrianratnapala 10y ago
  In my experience YAGNI-abuse happens when people apply it at the wrong level. For example, people might ignore some rule of the architecture in a rush to produce some feature. This sounds pragmatic: the feature worked, so that archtectural rule must be overengineering right? Then you ask why this particular feature was needed now at this point the project timeline, and why we had to throw aways fripperies like error detection to get it. Then I rarely hear clear answers.

by kev009 10y ago

skookum 10y ago

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.

dasil003 10y ago
The trouble with Ya Ain't Gonna Need It is that its counterpart You Are Gonna Need It has the same acronym.
adrianratnapala 10y ago
In my experience YAGNI-abuse happens when people apply it at the wrong level. For example, people might ignore some rule of the architecture in a rush to produce some feature. This sounds pragmatic: the feature worked, so that archtectural rule must be overengineering right? Then you ask why this particular feature was needed now at this point the project timeline, and why we had to throw aways fripperies like error detection to get it. Then I rarely hear clear answers.