4 ms·

I mainly disagree with the article. Most over-engineered monstruosities I've seen in my career don't come from engineers trying to uber-optimize their solution

by knocte 10y ago

I mainly disagree with the article. Most over-engineered monstruosities I've seen in my career don't come from engineers trying to uber-optimize their solutions to a sick level, but from noob/unexperienced/dumb programmers trying to get something done. Things like: methods with just one line of code (to call another method), classes that seem to be there just to satisfy some dubious OOP pattern, too many levels of error handling which can be simplified by just removing them and catch the exception in a single place of the program (at least in exception-based languages), too much 'public' elements in a class (justified by the programmer thinking: "just in case" someone needs to access them in the future), excessive interface use due to the (clueless)need of pedantic levels of unit testing, NIH-retards creating frameworks/ORMs/libraries for every single component their software needs (I even saw once a tech lead that replaced all uses of hashtables in the company by his own implementation which, hey, let you look for keys in a case-insensitive way!), choosing low-level languages to implement non-performance-critical software, and a big etcetera.

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 ago
  Thing 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.
loup-vaillant 10y ago
> too much 'public' elements in a class (justified by the programmer thinking: "just in case" someone needs to access them in the future) I've seen someone 15 years my senior make that mistake; then take issue when I removed the unnecessary code. He eventually had me fired. The "just in case" thinking is often used to justify some otherwise useless OO looking pattern, which once implemented is difficult to excise, because the alternatives tend to look less "OO" and less "pattern-y".
- Can_Not 10y ago
  > I've seen someone 15 years my senior make that mistake; then take issue when I removed the unnecessary code. He eventually had me fired. You deleting his extra "thinking ahead" code was subversive behavior and you deserved to be fired. You might technically have been right that his coding preferences were suboptimal, but it's not your place to (from his perspective) randomly delete good code. As far as I can tell, you blindly followed a clean code "quick rule of thumb" and butchered the bigger picture causing actual damages to productivity in addition to waisting your developer own time.
  - loup-vaillant 10y ago
    It's more complicated. First, I only touched code I was meant to use or update. Second, the guy refused to review my code until much too late. Third, he had me suffer his daily sarcasms practically from day one, sometimes in front of the customer. The real reason he had me fired was because I treatead him like a peer (as I was told we were), while in fact he wanted to be the boss.
kyberias 10y ago
Let's consider your first example: a method with just one line of code. I'm not sure why you bring that up. There's nothing intrinsically wrong about a method that only has one line of code. That one line of code can, for example, contain a complex calculation and the method is an abstraction for that calculation. Even one line of code just calling another method can be quite alright if the method is, for example, part of an adapter or facade class. Of course this sentence seems to capture your thinking: "excessive interface use due to the (clueless)need of pedantic levels of unit testing"
- knocte 10y ago
  > I'm not sure why you bring that up. Sorry, forgot to give more details: a private method with a single line of code. That is: something which can be simply done in the caller. > Of course this sentence seems to capture your thinking: Yes, unit testing can be excessive too. Of course I'm more against zero unit testing than excessive unit testing, but each test is an investment, and the optimal approach is, as usual, somewhere in the middle.

by knocte 10y ago

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 ago
Thing 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.

loup-vaillant 10y ago

> too much 'public' elements in a class (justified by the programmer thinking: "just in case" someone needs to access them in the future) I've seen someone 15 years my senior make that mistake; then take issue when I removed the unnecessary code. He eventually had me fired. The "just in case" thinking is often used to justify some otherwise useless OO looking pattern, which once implemented is difficult to excise, because the alternatives tend to look less "OO" and less "pattern-y".

Can_Not 10y ago
> I've seen someone 15 years my senior make that mistake; then take issue when I removed the unnecessary code. He eventually had me fired. You deleting his extra "thinking ahead" code was subversive behavior and you deserved to be fired. You might technically have been right that his coding preferences were suboptimal, but it's not your place to (from his perspective) randomly delete good code. As far as I can tell, you blindly followed a clean code "quick rule of thumb" and butchered the bigger picture causing actual damages to productivity in addition to waisting your developer own time.
- loup-vaillant 10y ago
  It's more complicated. First, I only touched code I was meant to use or update. Second, the guy refused to review my code until much too late. Third, he had me suffer his daily sarcasms practically from day one, sometimes in front of the customer. The real reason he had me fired was because I treatead him like a peer (as I was told we were), while in fact he wanted to be the boss.

kyberias 10y ago

Let's consider your first example: a method with just one line of code. I'm not sure why you bring that up. There's nothing intrinsically wrong about a method that only has one line of code. That one line of code can, for example, contain a complex calculation and the method is an abstraction for that calculation. Even one line of code just calling another method can be quite alright if the method is, for example, part of an adapter or facade class. Of course this sentence seems to capture your thinking: "excessive interface use due to the (clueless)need of pedantic levels of unit testing"

knocte 10y ago
> I'm not sure why you bring that up. Sorry, forgot to give more details: a private method with a single line of code. That is: something which can be simply done in the caller. > Of course this sentence seems to capture your thinking: Yes, unit testing can be excessive too. Of course I'm more against zero unit testing than excessive unit testing, but each test is an investment, and the optimal approach is, as usual, somewhere in the middle.