Technical Debt: Divide and Rule. Tips to Reduce Costs of Rework

Table of contents

    Get a free consultation

    Companies always have technical debt, as there is no ideal app, ideal product, or ideal startup. Emerline experts share their tips to minimize tech debt, uncover the value of its precise calculation, and explain when having technical debt is strategically sound.

    Types of technical debt and causes for them differ. Tech debt could even be a strategy.

    What are the most typical scenarios of tech debt occurrence?

    The first common case is business pressure. When the business is speeding up and we have a lack of time, there is no other way but to find a compromise and deliver the solution in the  shortest term. Later on, it’ll need certain enhancements.

    Another case is related to purely technical issues and continual changes in one and the same feature caused by the feedback from users.

    Rapidly changing requirements and new functionality wanted ASAP result in additional works that prioritize deadlines.

    Also mind that a technology is not a constant — with each technology obsolescence and improvements needed, new tech debt may arise. 

    Can tech debt be deliberate?

    Sure. Occasionally, our team intentionally incurs technical debt to reduce time to market. It is an approach applied for some of our startup clients who bet on tempo and strive to quickly check out an innovative idea to understand whether it is worth spending resources in the future.

    Such technical debt examples turn into a project strategy. We deliver a software feature or MVP in no time, test it, and then refactor completely in case of positive user stories.  

    This game plan might also work for the enterprise customers if their case permits. Generally, when we deal with huge corporates, the key challenge is clarifying the business value of technical debt.

    Businesses generally have a negative attitude towards tech debt. Our mission is to prove that timely tech debt fixing leads to business success.

    How to deal with technical debt taking into account customer engagement in all project activities?

    Accurate technical debt tracking allows our team to provide customers with a set of metrics (number of bugs per one product feature; time spent on adding a feature; number of commits per file; and others), which demonstrates that making time on refactoring is strategically wiser than frequent changes in the software.

    Refactoring often turns out to be a proactive measure to reduce time and costs of implementing new product features.


    Tech debt: if there is impossible to avoid it, then minimize.

    Well, you know how to measure technical debt and determine its impact on business. What about your strategy for reducing technical debt?

    Do not let your technical debt thrive.

    That’s our number one rule. Among our project cases is the development of Node.js software. We have been involved in the project with the already built up tech debt. After the project audit and negotiations with the customer, it was decided to invest resources in tech debt fixing. Currently, up to 30 per cent of the time is devoted to refactoring. This approach promotes further improvements of the software solution.

    Rely on careful planning and utmost transparency of requirements

    Our team is always focused on building trusted relationships with the customers. It helps us be aware of any project shifts and movements. When we synchronize regularly and know about all upcoming milestones, it’s easy to consider possible gaps, predict the most productive development and implementation scenarios, and prevent a tech debt increase.

    Enable clear documentation and ‘clean-off’ dates

    When tech debt tracking process is impeccably arranged, you’d hardly miss one that will negatively affect further development. We record every issue, prioritize them, and schedule regular times to ‘pay tech debt off’ thus keeping it under control.

    To sum up, no matter why tech debt occurred — prevent it from building up. Even if the prompt release is top priority, do not delay refactoring. Keep technical debt tracking in order to enhance software solutions gradually. Transparent, results-oriented, and trust-based relationships with customers become an important aid in accurate planning and technical debt estimation. 

    Recommended for you