Personally, I find the term "over-engineering" to be about as helpful as describing code as "bad." Baked right into the word is relativism centered on the speaker's axiomatic perception of themselves as the correct arbiters of "Goldilocks engineering." In other words, I would define "over-engineering" as "a descriptor indicating that the speaker doesn't fully understand the context of someone else's design decision, but knows they don't like what they do understand."
To give this a concretion, I spent a bunch of years doing a specialized form of management consulting that involved using static analysis to help enterprise IT leaders make decisions about codebases. In other words, I earned a living analyzing codebases and the decisions of the engineers who brought the codebase to its current (usually bad, since people never called me to tell me how great things were going) state.
This led me to find myself looking at a lot of codebases that had what most would probably agree was "over-engineered solutions." Here are some particularly fun ones:
A DTO code generation scheme that... also generated unit tests for those DTOs.
An application consisting of multiple "layers" of degenrative pass-through calls.
An interesting character that created a new flavor of MVC that he called "MVCD," where the "D" was his first initial.
A Winforms app that achieved "multi-tenancy" by generating every token in a SQL query with a complex stringbuilder scheme, tuning them with every token based on the logged in user.
The list goes on.
But here's the thing. "Over-engineering" is a judgement-assigning, dimestore root cause analysis that doesn't matter. Those designs had actual, tangible problems that had nothing to do with what the designer was (over) thinking:
Unit testing property bags has little, if any, regression detection capability for the cost.
Do-nothing application layers create maintenance overhead without any encapsulation upside.
New people onboarding to the team will be familiar with MVC, but not with "MVCD," so you're burning money on staff learning curve for no apparent reason.
That Winforms app took something like an average of 30 seconds to do anything that hit the databse.
So, I guess for me the tl;dr is "when cataloging issues with a codebase/design, and especially when communicating them, I try to stay away from personal taste and deal instead in cause/effect reasoning and tradeoffs being incurred by the design choice."
I guess you heard that you overengineered stuff enough to dig yourself in a defense of it. That will be a tough one to defend, especially considering how often startups fail because they are polishing their kubernetes config and polishing CI instead of getting paying clients.
Example:
I can perfectly understand react app, but when i see business card-type of page done in react+redux, its overengineered. Period.
Even if I didnt understand it, i can still judge when someone is clearly using wrong tools for the job.
I imagine that always settles the matter at code review for you, especially when you yell it. Glad you showed up to correct me!
(BTW, what you're describing -- speculatively adding unneeded functionality -- is called gold plating. People commonly use "over-engineering" to describe something else)
Personally, I find the term "over-engineering" to be about as helpful as describing code as "bad." Baked right into the word is relativism centered on the speaker's axiomatic perception of themselves as the correct arbiters of "Goldilocks engineering." In other words, I would define "over-engineering" as "a descriptor indicating that the speaker doesn't fully understand the context of someone else's design decision, but knows they don't like what they do understand."
To give this a concretion, I spent a bunch of years doing a specialized form of management consulting that involved using static analysis to help enterprise IT leaders make decisions about codebases. In other words, I earned a living analyzing codebases and the decisions of the engineers who brought the codebase to its current (usually bad, since people never called me to tell me how great things were going) state.
This led me to find myself looking at a lot of codebases that had what most would probably agree was "over-engineered solutions." Here are some particularly fun ones:
The list goes on.
But here's the thing. "Over-engineering" is a judgement-assigning, dimestore root cause analysis that doesn't matter. Those designs had actual, tangible problems that had nothing to do with what the designer was (over) thinking:
So, I guess for me the tl;dr is "when cataloging issues with a codebase/design, and especially when communicating them, I try to stay away from personal taste and deal instead in cause/effect reasoning and tradeoffs being incurred by the design choice."
I guess you heard that you overengineered stuff enough to dig yourself in a defense of it. That will be a tough one to defend, especially considering how often startups fail because they are polishing their kubernetes config and polishing CI instead of getting paying clients.
Example:
I can perfectly understand react app, but when i see business card-type of page done in react+redux, its overengineered. Period.
Even if I didnt understand it, i can still judge when someone is clearly using wrong tools for the job.
Period spelled out? Wow, you must be right.
I imagine that always settles the matter at code review for you, especially when you yell it. Glad you showed up to correct me!
(BTW, what you're describing -- speculatively adding unneeded functionality -- is called gold plating. People commonly use "over-engineering" to describe something else)
Cool.