Skip to main content

Managing technical debt of your products

You and your team are working on a new version of the product. There is an strict deadline that you simply can't meet within high-quality standards, and you are not allowed to cut corners of these must-have features. After explaining the situation to your manager, she responds that this is a business decision and that you have to do whatever is necessary to meet this deadline. In other words, you need to do some low-quality work which should be reviewed and enhanced in the future.

Does this scenario sound familiar to you? This is the most common example of technical debt, but we are not just talking about unclean code that needs to be refactored. Other types of technical debt are bad design, insufficient test coverage, poor integration, etc.

Sometimes it is necessary to take on some debt for compelling reasons, such us going out of business otherwise, or being the first to market. However, the decision makers must have in mind that it is a loan after all, and it has to be repaid one day... with interests. Taking on technical debt means taking a loan today against the time required to do future work, so the greater the debt today, the slower the team's velocity tomorrow.

There is a limit, called tipping point, when the product becomes unmanageable or chaotic, and even small changes become major occasions of uncertainty. Make sure that you have repaid your debt before you arrive to this unpredictable point.

Other consequences of technical debt are frustration, underperformance, decreased customer satisfaction, rising development and support costs, etc.

The best practices to repay technical debt are:
1) Commit to do high-quality work so that we don't add new technical debt
2) Clean up whatever happened-upon technical debt that you reasonably can
3) Devote a percentage of your time (5%-33%) to specifically repay targeted technical debt

However, there are at least three scenarios under which technical debt should not be repaid: product nearing end of life, throwaway prototype and product built for a short life.

Remember: technical debt, like financial debt, has to be managed. Don't underestimate it's consequences.

Popular posts from this blog

How to disable cookies on Google Analytics so that you don't need a consent banner

The integration of Google Analytics into a website or blog is not GDPR-compliant by default . You must first obtain explicit consent of the end-users to store cookies, describing in your privacy policy how you intend to use collected personal data. This is the reason why most websites nowadays display an annoying (but necessary) consent banner. If you fail to do so or if you only ask for implicit consent, you are at risk of being fined. However, it is possible to disable cookies on Google Analytics (GA) respecting end-users privacy, so that you don't need to ask for consent. The downside is that you will not be able to distinguish the type of user (unique vs new vs returning) and you will miss some session insights. If these details are not relevant for you, here is how you do it. Disable Google Analytics cookies on a custom website If you have a custom website with full access to the source code, you can simply insert the script below between the <head>  and </head>

How to convert a PWA into an Android app in 5 minutes

In early 2021 I developed a memory game called Kobadoo  as a PWA (Progressive Web App) using ReactJS. It works pretty well as a browser game and gets decent traffic, but I wanted to reach more potential users by making it available on the official mobile app marketplaces. Since I didn't want to spend any time coding a native app, the easiest solution I found was to convert the PWA into a TWA (Trusted Web Activities) app. It barely takes 5 minutes to do it. TWA essentially allows you to easily create an Android app ( .apk file) that displays a full-screen browser view of your PWA. The user experience is almost identical to a web app and the views from the TWA will count as traffic on your web app. This means that if you have ads on your PWA, they will still work (and generate revenue) from the TWA. Another advantage is that every update you make on the PWA will be immediately reflected on the TWA without the need to submit a new version on Google Play. Here's how I convert

How to jump to time offsets in HTML5 video

Let's say that you have a 30-minute WEBM video file, from which you just want to play the following video segments , jumping from one to the other automatically  without interruptions : [00:01:25.00 - 00:02:25.00] -> from second 85 to 145 [00:11:40.00 - 00:11:55.00] -> from second 700 to 715 [00:20:26.00 - 00:21:07.00] -> from second 1226 to 1267 [00:26:11.00 - 00:28:01.00] -> from second 1571 to 1681 To increase the complexity, let's think that you have these video segments in a PHP variable $arrayVideoSegments  (normally the case if they were retrieved from the database).   $arrayVideoSegments[0]->startTime = 85   $arrayVideoSegments[0]->endTime = 145   $arrayVideoSegments[1]->startTime = 700   $arrayVideoSegments[1]->endTime = 715   $arrayVideoSegments[2]->startTime = 1226   $arrayVideoSegments[2]->endTime = 1267   $arrayVideoSegments[3]->startTime = 1571   $arrayVideoSegments[3]->endTime = 1681 The fo