gap intelligence cares deeply about the quality of our data and the services we provide to our customers. Since the early days of gap intelligence, we’ve created solutions that allow us to track and analyze trends. We critically look at changes in the marketplace for e-commerce as well as brick-and-mortar retail throughout the US. As part of our 2020 initiative, we’ve expanded our presence into Europe. This expansion required our Product Development department to add the ability to store multi-country data in our data warehouse.
The result of our work not only grew the capabilities of software solutions, but also our experience. During the development process, we found that tech debt in applications can slow down development or complicate its process. In this blog I am sharing the experience of how we managed and reduced our tech debt.
What is Tech Debt?
Tech debt is hard to imagine, but it’s similar to financial debt (Eugene Correia’s blog on Tech Debt does a great job explaining what it is in depth).
Imagine that we want to buy a new MacBook for $ 2,200. You can save money during a year at $200 per month and buy one in a year after. Or you can purchase with a credit card, but you will have to pay every month. If you don’t pay the bill monthly or you only pay minimum payments to get by, the debt will increase.
In the development world, debt can consciously or inconspicuously appear. Tech debt can be divided into the following categories:
The debt in the codebase or architecture usually appears during the development process and is associated with a lack of information or experience about the field, lack of tests or documentation, a strong connection between the components of the system, delayed refactoring. Such a debt can be created consciously in favor of achieving the goal.
The debt in the processes is manifested in the form of repetitive actions that developers need to do periodically, and the implementation of such actions takes significant time. For example, you have an issue that frequently happens, and in order to collect information about each case, you need to look at the logs on different servers, take the user ID in database #1, find the record with this ID in database #2. Such actions may be considered a tech debt. Besides debugging, tech debt in processes may include setting up a project, a complex deployment, long-running or complicated tests launch or build.
When to Start
When developing a new feature, if you find that some code can be improved, one of the best practices for trimming tech debt is making that code part of the task you are working on. Improvements should occur in small chunks and in the context of the task at hand. Thus, with each change, the code base will improve, which will reduce tech debt overall. Some tech debt can be ignored, since its impact on development speed or processes is very small. If the development of a new feature slows down by tech debt, it is better to pay off such a debt before building something new. Otherwise the debt may increase over time or affect the deadlines.
Where to Begin
First of all, it is necessary to explain to the business the importance of paying tech debt. Tech debt alone may not be valuable to the company, but it may directly contribute to the achievement of goals. Thus, together with current tasks, you will be able to pay off tech debt. If the deficit is large, then it makes sense to spend an entire sprint working on tech debt only.
The following steps allowed us at gap intelligence to identify and organize our existing tech debt:
Debt Identification: Debt can be both external and internal. If you ask an engineer, most likely you will immediately get an answer as to what kind of tech debt exists in the application. Such debt comes from an internal source. On the other hand, customer experience is an external source. It may include performance or repetitive activities that take a significant amount of time for the user to accomplish a task.
Categorization: After the list of tech debt is collected, we assigned specific tags or labels to each element of the list. Tags can be different, and depend on the project and the type of tech debt. We used such tags as product name, performance, scalability, security, dependencies, ux/ui, and maintenance. These tags helped us organize the list more efficiently, combine similar ones, and understand the amount of tech debt that we have. Similar to financial debt, it’s best to start with debt you pay the most interest on. In some cases, priority may be given to debt that will bring more value to your customers or more impact to your Roadmap development.
Planning: In our case, part of the tasks to reduce tech debt was combined with the tasks on our Roadmap, which allowed us to accelerate the development of new features. The remaining tasks will be incrementally and strategically added during ongoing sprint plannings.
Implementation: Tech debt tasks can affect many system components, including file storage, caching, and the database. While paying off, it is important to consider the possibility of incremental delivery of changes to production. This way you can break down tech debt into smaller tasks and minimize the risks of breaking production.
Inevitable Management
In the development process, the emergence of new tech debt is inevitable. It is important to periodically review the code base, processes, and documentation associated with all projects. To facilitate the process of identifying tech debt our product development team creates tasks that describe all discovered tech debt.
As developers tech debt allow us to move faster when we need it but do your best to avoid it. Collecting tech debt is not recommended since it can become crippling and it may become the reason why moving forward is impossible.
For more than 17 years, gap intelligence has served manufacturers and sellers by providing world-class services monitoring, reporting, and analyzing the 4Ps: prices, promotions, placements, and products. Email us at info@gapintelligence.com or call us at 619-574-1100 to learn more.
