Table of Contents
When talking to developers, I sometimes notice how difficult it can be to promote the implementation of a certain feature or to introduce new functionality to the projects. There are many reasons for this bottleneck: no time, pressing deadlines, even simple unwillingness to tweak the project. Other big reasons include the sluggishness of the project and the client’s intractability. I’ve also faced cases when a client demanded introducing certain tools without any justification for that.
In this article, I’d like to talk about my recommended method of implementing new functionality or promoting code refactoring and what should be taken into consideration. I hope these recommendations will help you tweak your project and boost your productivity!
A quick note on refactoring and its importance
It often happens that a software project becomes too slow, new implementations take too much time, or developers are simply confused about the code. All these might be signals for refactoring – a process that is highly important but also often overlooked.
Refactoring means restructuring the existing code without changing its external behavior and is performed to make the code cleaner and more readable. In this way, the productivity of the project improves and it becomes easier for developers to work on it and adhere to set delivery deadlines.
Code refactoring vs rewriting
Note: do not confuse refactoring with code rewriting. Refactoring means implementing micro changes to the code and cleaning it up while rewriting is exactly what it sounds like: rewriting the whole app from scratch.
So when to choose refactoring and when to choose rewriting? In simple words, look at the cost of the outcome. It might happen that code refactoring turns out to be more expensive and long-term than rewriting – in this case, the decision will be quite obvious.
Getting back to the issue of introducing new functionality or tools, I’ve come up with a plan of action on how one can organize the process in a way all parties involved are satisfied with the outcome.
Evaluate the real need for the change
First of all, you need to adequately evaluate the need for implementing a new feature or a tool on your current project. Here are a few questions that you may ask:
- How much does the team need the proposed change?
- How many people will be interested in this task?
- How will you explain the tangible benefits to the client?
One of the biggest bottlenecks that you might face at this stage is people asking why change anything when the whole project works? If we take code refactoring, for example, there are several symptoms that indicate an acute need for it:
- even the smallest tweaks take too much time because the code is too messy;
- developers cannot accurately estimate the time needed to complete a task because they have to puzzle out the code first;
- you need to implement the same changes to different areas.
Altogether, these issues lead to prolonged or missed deadlines and extra work – and that’s the reason that you’ll base your arguments on. The same logic applies to proposing new functionality: you can compare the current state of the project with its forecasted future state after implementing the proposed change.
Identify involved stakeholders
From the developer’s point of view, the introduction of code refactoring, a new tool, or a new feature brings clarity to the code and facilitates work. But how do you explain this to the client?
Therefore, your next step is to identify all involved stakeholders and their interests. When talking to the client about the need for change, you might stress out that the project will become more stable once the code is cleared and better organized. Another powerful argument is that it will be more difficult to attract developers to an outdated tech stack and the project entry will reduce significantly.
As for the development team, the benefits may include a faster delivery of features or easier detection of implicit errors during the assembly and deployment stages. And don’t forget about the project manager: the proposed change may allow them to retain the current task realization speed (or even boost it), improve planning and management, and increase the deadline estimation accuracy.
Prepare technical justification
The next thing that you need to take care of is preparing a technical justification for the proposed change. At this stage, you need to answer the following question: what will the project gain as a result?
In order to answer this question and come up with a reasonable answer, you need to fully analyze the promoted technology/tool/feature and understand its pros and cons. You will also need to outline in which cases a new approach adds problems and in which cases it solves them.
List possible losses in case the change is not adopted
In addition to listing the possible benefits that the change might bring, it’s also a good idea to outline the possible losses in case the client and/or the team decides to neglect your proposition. These losses might include:
- Financial risks due to missed deadlines;
- The decline of project efficiency;
- Project slowdown.
Sometimes, a client is not persuaded by “positive” arguments – in this case, the “negative” arguments listed above can play a really big role.
A word about technical debt
Technical debt is an important argument to discuss when talking about the possible drawbacks of neglecting the proposed change and refactoring, especially. To define it, technical debt is the cost of additional work that piled up as a result of the team ignoring bugs and messy code. It most often happens when you go with a “good enough” approach, i.e. leaving a few bugs behind and not thinking about their long-term impact on the project.
Even though a technical debt can be deliberate (meaning, you understand that you have this issue), it is never a positive thing to deal with. So when talking about the need for refactoring, it might be a good idea to estimate the current and the future technical debt and present the numbers to stakeholders.
Final word
As a professional developer, one needs to know how to present information in such a way that all your arguments sound reasonable for all stakeholders. But if you did your best but no change was implemented, don’t worry. If your expectations were correct, they will 100% come to life and next time you propose something new, neither the client nor the manager will be able to ignore your words.
Therefore, my advice is to work on your communication skills constantly in order to clearly communicate your thoughts and ideas to colleagues, managers, and clients. This will help you in the future and will move you from the position of a developer who just implements features to a knowledgeable expert who gives valuable advice.
Comments