How do you spot over-engineering as it is happening, how do you communicate around this issue?
For further actions, you may consider blocking this person and/or reporting abuse
How do you spot over-engineering as it is happening, how do you communicate around this issue?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (48)
I'm guilty of this a lot. And it requires my teammates to tell me that so far. I feel like maybe it's a step-back-and-look thing. Or maybe stopping before diving straight into a problem and trying to see if there's already something in an existing lib or codebase to do it simply.
In my side projects, I know I've over-engineered when not even Git could save me from my spaghetti code... 😔
I've seen many software engineers implement things that aren't in scope of their projects just because:
These are all warning flags for me, as an engineering manager, that the engineers will potentially over-engineer things that bring zero value for the customer.
When we follow the lessons of V-Model:
What I'm saying is, each step is based on the previous one and each step must be verified against the previous one. Anything else is over-engineering unless there are other business cases behind it.
You shouldn't identify over-engineering as it is happening because it might be too late to change direction. You should prevent over-engineering from happening.
Although there is a big advantage to stepping back during the design process and thinking of extensibility or abstractions which will allow features to be expanded easily, or suit alternate approaches without mass refactoring. Sometimes, these thoughts come at a later implementation phase, and we have had big wins by doing iterative stuff at a later point to "enhance" the offering rather than go back via the planning and design phases.
There is a big difference between "gold-plating" and forward-thinking, and the line between the two is extremely fine and easy to end up on the wrong side of!
I agree, and I think the difference is in how you approach it. You want to leave yourself open to extension, but not over-extend.
Start from the Minimum-Viable-Product and then iterate from there. If there are pet pieces that the developers would like to make along the way then you let your customer handle prioritizing that work.
There is another side of this issue that you mentioned. If people are trying to push projects into a new language then they obviously have interest in learning something new and are not given an outlet for that energy. Letting them get some down time to work on a small pet project to learn a new language and report back as to how it performs would be great. Help them to understand that there is a time for experimenting and the Customer's product should not be that.
Great comment
keren sekali penjelasannya mas galuh saya terpana
Amen.
I know a few people who are overengineering stuff all the time, just for the sake of what if... Meanwhile, there are a bunch of serious problems with the apps they're working on. I guess that most of them hope that the problems would just go away on their own.
GREAT post!
how do you address over engineering when the person who is doing is the architect/fo-founder.
lets build a user management system with log-queue pattern, you know so each web app can manage their own users (which they dont, all collections need to be in sync otherwise the app breaks). have 3 micro service, one which for crud on the source and the other two are responsible for replication.
WTH.
Anything for the future is not for the now so should be looked at with a sceptical eye.
I just spent 2 evenings on a personal project trying out different sub module and other strategies but in the end it all felt insane so I just stopped. No with that distraction out of the way I managed to refine my release scripts so that they at-least work.
Using external libs for trivial problems. Reinventing the wheel isn't good but very often the real problem is easier to solve than people think.
Also, forcing to use design patterns everywhere without thinking if they match requirements makes code crappy after time. They are for special purposes but some people are trying to put them everywhere.
I've been guilty of the latter. It used to be that when I found a new pattern I would put it everywhere. I justified it by telling myself that I was learning about it, but all I was doing was stalling a release. Quick and dirty, while not always the best solution, isn't always the worst, either.
When a team mate reviews your code and spots on code style, not the business rule and its flow.
I think over engineering can often be synonymous with over abstracting. As developers, we often build abstractions to future proof our software. Unfortunately, we can often plan for a future that doesn't exist. Since we get more information about the future as time goes on, it can be a better practice to defer building abstractions until we have more information. This helps us avoid unnecessary complexity, and make decisions based on data, rather than guessing :D
Sandi Metz has an awesome article about this topic. sandimetz.com/blog/2016/1/20/the-w... This article has some great words of wisdom in it "duplication is far cheaper than the wrong abstraction" and many others.
I think Jeffrey Way would agree about over abstraction. When I was learning Laravel, a lot of times he would say to not worry about abstraction until it became clear that a part of the code was going to start getting messy. He'd also show a good number of ways to accomplish the same thing, depending on what's needed.
If code review is not a must and not being value by stakeholders, under engineering is the only concern. Over-engineering can start with choosing a framework or importing 3rd party libraries, but deadlines are always the top priority.
when every little change is so expensive and time consuming
This can be a symptom of ‘under engineering’ too - ie just piling features on features on features and never paying down tech debt
yes, this is why I think finding the correct solution is a very valuable skill. Not under, not over engineering.
Could you write less code to solve the stated problem(s)?