Over-Engineering is something most of the developers I know struggle with. Nevertheless, the term is also very subjective. What is over-engineered for developer A might be a perfect strategic step in the right direction for developer B. (in the following section the italic sentences are direct quotes from hackernoon here)
Over-Engineering is subjective and the damage of its subjectiveness increase as the requirements fail to present the full picture of the problem
So to define the term:
Over-Engineering is when someone decides to build more than what is really necessary based on speculation
So if we assume that speculation is the root cause then the following quote is the logical consequence:
To reduce the chances of considering something as Over-Engineering we need to understand the problem and to understand the problem we need to clarify the requirements as much as possible by asking "why"?
But there is more than that... Further Reasons (as described in cloud-foundry on youtube here):
Over-Engineering is subjective and the damage of its subjectiveness increase as the requirements fail to present the full picture of the problem
So to define the term:
Over-Engineering is when someone decides to build more than what is really necessary based on speculation
So if we assume that speculation is the root cause then the following quote is the logical consequence:
To reduce the chances of considering something as Over-Engineering we need to understand the problem and to understand the problem we need to clarify the requirements as much as possible by asking "why"?
But there is more than that... Further Reasons (as described in cloud-foundry on youtube here):
- consider the data
- like:
- how often are things used
- how often are things changed
- how long does a process take
- is the process responsive
- ...
- we don't have it (green field, bad data gathering)
- it might be too early to make a decision for further engineering (refactoring)...
- will we have the data somewhen?
- can we ask someone?
- do we really trust this guy?
- do we ignore the data and might make bad decisions
- even if something is crap:
- is it worth changing it?
- return of invest?
- do we have use-cases that work out better by improving the software
- unnecessary complexity because of pride
Further reasons (as described in build stuff-youtube here):
- we are not listening to what we need to deliver (bicycle -> spaceship)
- frameworks don't deliver value (even if funnier to solve any problem then one specific)
- business guys are responsive to risk and not preventative so not implementing stuff might be ok for your product owner
- don't focus on all the things that might go wrong, but recognize that you're still on the happy path (that nothing went wrong right now)
