Fighting (perceived) overengineering vs going with the flow [closed]
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
I joined a team which has a different approach to design from mine. I believe in YAGNI approach to design. For example, if a method (interface, class) is unused, it has to be removed. That's it.
People in my team are building a modular app, and one of the modules is perceived as "framework". The app is the only user of this framework, and there are no plans right now for it to have more clients. However, parts of the code in this framework is written and maintained as if it may be used later, and consistency and completeness wins over YAGNI. There are abstractions in places that may never be in need of abstractions, etc.
I tried to argument a few things away, but each point takes a lot of time to persuade, if at all, and I'm afraid that too much "pushing" will result in team breaking up into opposite sides.
I can "go with the flow" and write extra code without any personal issues. It will take me more time now to code, and most likely, more time later to maintain, however, each discussion to not do something extra also takes time and adds pressure.
The question is, in the case of different opinions, what will do a bigger disservice, unneeded but "proper" code, or constant arguments and broken team dynamics?
Solution
Maintaining an imaginary framework is an architecturally significant decision, so the question boils down into “how do we come up and evolve the architecture” in the team. You have to start with well-defined decision-making rules that are clear and embraced by everyone in the team because there is no game without the rules.
When joining the company, one of the most important questions you may ever ask is –
How does the decision-making process work in the team and how does it evolve over time?
No decision-making process is worse than bad decision-making process. if there is no process, someone needs to define one. Otherwise, the amount of nonsense grows together with the amount of disagreement withing the team.
I think with this we are closing the loop – either you have an authority and power to define the decision-making process when it’s missing OR you agree with the current process / and how it evolves. Choose one.
OTHER TIPS
Constant arguments and broken team dynamics will never get you very far.
I would try to get an understanding of why there is a framework in the first place.
Most likely the reason is that it is expected to be used in other systems later. If that is the case then it makes sense to do more than is needed right now.
The reason for that is if one app is in production a new app is underway requiring updates to the framework then every time something is changed in the framework, perhaps abstractions that weren't needed earlier are added, then the original app has to be updated and tested as well.
That is an awful lot of refactoring and retesting for something in production.
If you chose not to include the updated framework in the old app, then you have 2 frameworks to maintain one of which is already obsolete.
Maintaining obsolete code is not very good for morale either.
If you're new to a team, trying not to be a disturbance in the force should be your first concern.
I'm assuming you're not in a lead/architect position, and the decisions are not up to you.
The second concern is Learn. Learn a lot. Learn why they took the decisions they took, why the framework was created, what is the rational behind that. When you have all the information, then you can take an informed decision about how to approach possible problems, such as overengineering and bad communication.
Ask questions, in a polite way. Put yourself in the position of a student, and not a master. It'll make easier for people to "teach" you why they did things that way.
Right now you're the outcast. You're joining a foreign team, and you should learn their customs and adapt yourself.
If you do your job the right way, with polite approach to people, people will naturally listen to you over time. And then, if you're absolutely right that your approach is the best one as a whole, you can influence people to change.
I've hardly known anyone who likes to work with a person who often criticizes, but don't generate value. Be a reference to your team, someone they're proud to work with.
Also, recommended reading: https://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034
There are 2 fundamental things I think is happening. The first is cultural. You are new to the team and you haven't quite figured out how to work with this team. They probably have different policies and practices that may actually work for them. Also one or more of them may have applied for your position and so they may be actively sabotaging your efforts or just not telling you what you need to know.
The second is that you have possibly misread the design. The part that you think is dead code may actually be a generalization of other parts of the design or it may be working towards supporting something that the business wants to eventually support. It may actually be dead code. Stop obsessing over it and understand why it is there. It may actually take months to figure out.
In risk averse industries (i.e., banking, medial ... ) where there is the slight possibility that a chunk of code may be used, that chunk of code will linger for decades.
To highlight this, one of the stranger database structures I have seen centered around 6 tables. 3 of them were mapping tables that connected the other three. It didn't make any sense as the code indicated that only one them was being used as a many-to-many relationship and the other 2 were implementing one-to-many. The original designers of this had left and no one could explain exactly how or why it worked. Eventually, I came across a business document that explained the design - so my guess was that the business had asked for it and some DBA just implemented in a way that the business could understand - despite its obvious limitations. 30 years later it is still there, earning the company money - but from a development stand point difficult to understand, maintain and develop with.
I see some good points about having such a piece out of the application even if no one else use it.
This can enforce the development of technical functionnalities in the framework with their proper tests outside of the functionnal context of the application (and on its own roadmap).
Furthermore it might be possible that you don't want every developper touch that framework but only the most seniors ones, so again getting it outside of the application is a plus.
For the abstraction layers not needed, well if they are already there, don't change something that is already working.
However you might remember to your team for the future that the goal of the framework is to lighten your work, no weighten it.
Reading between the lines, I am leaning towards your co-team members. Making something "more complicated than needed" not only paves the way for possible future functionality that may never be needed, it also serves a developer's understanding of the application, it incorporates a model in the software, it documents an idea.
And doing so it restricts the way future developments may go. It keeps developers that do not fully grasp the design/intent from straying.
A new developer may at first be annoyed by the "unnecessarily complicated" design, but it also guides him in the right direction, it makes him fall into the pit of success and makes it harder for him to "do things his way", which would just be another way that would really complicate things because it would lead to different approaches in the same application, which makes it even harder for the next guy to get his head around it.
YAGNI does not (or should not) mean "you can skip the design" or "do it quick-and-dirty". If your team has the luxury of thinking things over I would say that is something to cherish rather than fight.
