I've seen many software engineers implement things that aren't in scope of their projects just because:
"hey, what happens if the customer needs this feature in the future? We must adjust the architecture so that it can accommodate that feature."
"hey, micro services are all the rage right now, we've got to have it for our next project"
"hey, this brand new shiny library looks cool. We must use it for this project."
"hey, the customer pays us a lot of money, let's use it to learn new languages and use for that project"
and so on ...
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:
There's requirement and use case analysis,
based on that you build a system design,
based on that you build a functional system design,
based on that you build technical system design,
and based on that you write the code.
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.
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.
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.
True full stack in #fintech. Analysis, solutionizing, developing and delivering.
Mostly working in dotnet and javascript, with a passion for process optimising!
hey, what happens if the customer needs this feature in the future?
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!
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
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.
GREAT post!
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.