by Sometimes when we are developing some chunks of code, we start to question why I am doing it this way? Should I do it in another way? Is there a lib that could make my work easier?
These questions are essential, so we create the most simple, reusable, and effective code daily, but the answers may not seem easy to begin. For example, let’s suppose that we could add a lib for doing our work better and faster, but we have to communicate with other people inside the project to use that. How do we approach them? Adding a lib, a technology, or changing an architecture perspective may seem hard to introduce, and this article may help you with that. Let’s start from the beginning.
The technology variable
First, how do you check if the technology you want to add to the project is needed? Try to visualize a scenario with it. What are the possible changes that you need to make to your codebase? Will the legacy code be impacted? What would happen to the tests if we added them? Would they break? Will we have performance issues? Is the rest of the team familiar with this technology? If not, is the learning curve worth it? Is there a reason it is not used already? Was this considered before? The code will run faster and is easier to comprehend, or it will be a bit slower, but the codebase will be cleaner and more consistent?
These questions will give you some arguments to use in your next step. But first, we should grab every answer and try to check the pros and cons. A good analysis of this step will make the next one a lot easier to prove your point, especially if the team is large because everyone will have an opinion of their own. So, what could we do if not prepare ourselves?
The human variable
Okay, so in this step, you already have your pros and cons in mind and are prepared for your teammates’ fundamental questioning. The next step is identifying what kind of team you are a part of. Is there a tech lead figure? Is there a space for developers to be open, speak and give suggestions in some regular meetings? If these answers are positive, an excellent way to approach is to use as much of the tech meeting in your favor. It is why the meeting was created.
But if these answers are negative, you’ll have an extra effort to present them to your teammates. So again, I strongly recommend you grab everyone impacted by these changes and give your suggestions. Sometimes, parts of our team are not able to participate in the discussions. The reasons are diverse, they may not be in the same time zone, or sometimes they are just hard to be convinced that this will not be a waste of time (remember: some people may be resistant to changes), so, in this case, we should grab our final variable.
The POC (proof of concept) variable
The name says it all. Most of the time, you must prove that you’re right to convince someone. Think of a scenario where the change you want to make will benefit. If you can think of multiple scenarios, that would be great. I recommend an everyday scenario where your changes will give light to the darkness, making your work easier to do. Build a POC, something that you can demo and compare with what you have now. At this point, everything is valid to convince yourself and your teammates that this is a good idea, and if you figure out that it is not, don’t get frustrated thinking you just wasted your time. Bring the results of your discovery to the team, good or bad. Feedback on this part is gladly accepted because they may have some opinions that can benefit everyone.
The "real deal" variable
So, your suggestion got accepted, and you started to implement it? Good! Or it isn’t? Some problems may happen because the team will probably get used to the new approach. Code reviews are essential to this procedure, so make sure you pay double attention to them. Remember: not everyone on your team may have the skills to use your suggestion immediately, and the person doing it wrong can also be you. Humility is the key to this step.
A nice to have is a material collection of how the transition went through. There, you can add study materials for the team members unfamiliar with the new technology, document the pros and cons to later know if both good and bad parts were expected or not, and discover when you were trying to implement.
Ensure to hear feedback and, above all, don’t refactor everything at once. Separate by pieces, little chunks keep everyone producing new tasks and changing old stuff until you reach your goal: introduce new technology to your team.
We want to work with you. Check out our "What We Do" section!
