How to get rid of tech debt and do not forget about business value?

It is not an easy task to decide about how to improve your product: you need to keep in mind tens of different factors, and each of them could be unpredictable. Nowadays, more often, technical teams starting to participate in business decisions. And one of those: strategy to work with tech debt issues.

I was lucky to capture this problem from the development, management and business perspectives. I am grateful to all who takes long discussions with me and arguing those opinions. I believe that approach based on the benefits for all works best. Although in practice, it is not entirely obvious how to bring it up to the company mindset.

Meeting

Managers (satisfied): We approved all the details, and we are ready to start working with a new feature!

Developers (not satisfied): we have an outdated library for charts generating, and we have a terrible sorting in the old module. We can’t deal with the project structure already six months after marketing team renamed a theme.

QA’s (with concern): upgrade with AmEx maps doesn’t work and custom themes are not applicable, we need to fix it in the next milestone ASAP.

On those meetings, you understand that all of your team members have different goals.
Business already f*cked up with the investments into development without a visible result. Team-lead knows that “spaghetti code” could be impossible to fix soon. On the last retrospective, QA spent 10 minutes talking about “what we should start doing” after the key users reported bugs directly to the CEO.

Product quality is super important for many of the tech teams, and when management once again refusing their request for refactoring, it will directly impact team motivation and enthusiasm. Sounds familiar?

We are for all the good

Those problems look very different, but they are the same. Business and QA want most important users don’t meet bugs. A company is interested in product improvements with a lower cost and as fast as possible timeline. Developments are interested in a quality codebase, which is easy to support and where they can add new features without a fear that they could meet unscalable legacy. So all of the above is related to the business goals:

• less important users — it means that bug will be a problem when it touches higher % of the target audience (those who increases a profit or can potentially increase it);
• lower costs = easy to maintain / add new features — it’s not about abstract features but only about the items that would be taken in progress soon.

Example of backlog

Let’s see in action (bugs don’t need to be counted as a tech debt, but often they are figuring near so let’s keep them in the eye). In the backlog we have:

All items must be considered. Bugs look really serious. According to the best practices, libraries must be updated on time, and sorting must be consistent everywhere, and total facepalm about folders. Okay.

In the meantime, all items on their own, don’t bother anyone until someone meets the problem. For example, poorly realized sorting in the old module will be a problem if someone will need to change something in this part of the code. The same with bugs: if you have a bug it’s doesn’t scary itself, all depends from the context — in what case users will get those bugs and how many people will be those users.
Let’s add a context to our items and describe why it is a problem.

Next, let’s learn what we have in the roadmap:

• onboarding for corporate clients;
• generate annual reports in the old module, use CoolAPI.

And, let’s get back to our meeting, where we are deciding what we are going to do next. Remember, “business” want’s ASAP, so developers need a maintainable code and all of you need as less as possible quantity of bugs for main users.

After closing those five items business will get a profit because the critical issue was fixed for “corporate client onboarding” and monthly they save 5 hrs of development.

Refactoring / bugfix context

While discussing the importance of backlog items, ask yourself (and others):

• which components or features are related to;
• which advantage does refactoring provide (for example, it will be easier to perform changes, or it will be possible to reuse the code, or move it into a separate component, and then adding a new same entity will take a minute);
• it is some new features that were planned to be implemented soon in those components;
• what kind of users would be affected (paid or free, main or minor)
• for bugs — how often they appear, for which use case, is there any workaround.

It does not make sense to consider such kind of tasks without a context: you can get a result that no one will need. Let’s say, the guys, on their own initiative and during off-hours, refactor a piece of the application, really do everything in order, they want to surprise everyone and expect at least gratitude pleasantly, but nobody praises them because nobody did need any work done at this stage.

The main problem of outsourcing (but also some in-house teams) is that everyone sees their own way and goals inside the product. There is no clear understanding and full transparency between business on the one hand and technical teams on the other. Business stakeholders could not share their plans; technical teams simply could not ask them about it. And even if the information about goals and plans are available for all, still those things must be discussed and presented to all members of the team, altogether with stakeholders.

Let’s «sell» refactoring

When you have a context knowledge and understand business goals for the near future, it will be easy to “sell” refactoring idea. And, from the other side, when you know how exactly spending time on refactoring could impact on the project, management people can better define right priorities.

Basically, we want to improve something, not for its self-improvement, but only to avoid further issues with product scaling, improvement, and development.

For example, let’s try to get acceptance from management custody, for framework update, that could take a significant part of working hours:

А. We need to update the framework because the longer we use the old one, the harder it will be to update it in the future. There is no value for the business.

В. We need to update the framework. The new version has the methods to receive data in X format and this will allow us to sent instant messages to the customers. Also, the performance of pdf exports will improve by 20%. If instant messages and export performance are crucial for business, then framework update will be accepted.

In A option, developers usually opened a question about long-term maintenance. Many of you face a lot of products where updating dependencies or refactor a code was already problematic, and on the early stage, it would be more comfortable. If there are arguments that “the update will definitely be needed later, so it is better to do it now”, then you need to bring them, and the option comes down to something like B.

If it is just with a context “for the future”, then there is a high risk of a negative result. The future may not come (project could fail). The future may be different (another framework will be developed). The old framework can be good for your needs (for the future as well), and of course, in many cases you really have to update the framework when it is too late. If at the time of making a decision the possibility of the last outcome is either small or unknown, then resources will not be allocated for it, because there will be higher priority tasks that solve real and visible problems at that time.

TL;DR

We are always trying to optimize all around us, to get rid of routine, switch making decisions to robots, simplify the processes. It’s human nature. Evolution. We are happy when we do something important. We don’t want to waste our time for something that never bring us a result. We want to build something and brag about it.

It is very easy to lost focus and context in our abstract everyday work. It is plenty of information, and we switc all the time between the levels and backgrounds of the data. Unfortunately, we could lose sight of something important, that will drive your team and your product to success.

• Having legacy or bugs isn’t that scary: it’s essential to identify what exactly could be a potential problem at the current time.
• Try to achieve a clear understanding of business priorities and the way how to improve the product. Only then you could argue bugfix and refactoring, and it will be a win-win situation. A business will get fast development, and developers would get a product that is easy to maintain.
• Get back to the topic: what exactly will be improved by proposed changes. Does it really matter?
• If you a CEO, share your vision and plans with your team more often. It will help to make the best architecture decisions and to avoid a tech debt.
• If you a Manager, obtain and then share the information about plans and context of refactoring and bugfix.
• If you a Developer, be aware of the most important features for the product. Help to identify critical tech debt, and bring a right context into the backlog.

Thanks for reading!

This article was translated from the source: https://dou.ua/lenta/articles/business-value-vs-technical-debt/