In Software Engineering, technical debts are short-sighted, easy, and quick design decisions that could result in long term cost for additional future rework, similar to financial debt
Be aware; that not all easy and quick decisions can convert into technical debt, sometimes early optimization or over-engineering may also make a bigger debt. Reworking technical debt originating from over-engineering or early optimization could sometimes cost a fortune in terms of development work hours and interest accumulation could be more compared to technical debt arising from quick and easy design decisions.
Interest is accumulated in terms of rework efforts that need to be put in, in terms of resources and efforts; with project growth, increasing more interest to be paid. Sometimes a system has grown so much that repayment of technical debt becomes impossible.
To manage technical debt, it needs first to be categorized. Here are a list of some categories worth considering and some opinion on how to manage it
Table of Contents
Deliberate technical debt
As the name suggests, developers are aware of these kinds of technical debt in the early project lifecycle; made deliberately. In the early project lifecycle,
- Definitions are insufficient
- Business pressure to reduce “Time to market”
- Lack of knowledge and/or lack of documentation
In the scenarios explained above, we need to take quick and dirty design decisions.
How to address
If you have to take those design decisions (in the agile era, requirements change with times and the team should be quick to respond to those changes) for reasons listed above, better to note them down and address as soon as possible (early repayment will cost less). But if possible deferring those decisions later when requirement becomes clear are also advised
Continuous refactoring is advised to for servicing debt and keeping interest lower
Accidental/outdated design technical debt
This category can be broken down into two, but I kept it in one for sake of simplicity. While designing a system a developer tries to balance future-proofing simplicity and quick development. This is a very tricky balance and nobody gets this correct every time. As system evolves and requirement changes, you may realize that your initial design was flawed. As system evolves, this kind of technical debt makes it hard to improve upon after a certain limit. And that’s where you know of accidental design technical debt.
For outdated design technical debt, we sometime use open source dependencies that have been long been developed and not actively maintained or they may have upgraded and you have not maintained pace with it. Sometimes we use proprietary dependencies for which licenses have not been purchased or there are fewer resources out there, having an understanding of those proprietary dependencies. In this case, hiring a dedicated resource or effort become costlier with times
How to address
- Learn from accidental technical debt and correct as soon as identified
- Replace outdated system dependencies as soon as identified, if upgrading is not an option
- Keep upgrading dependencies as soon as possible, this keeps technical debt serviced at a lower cost than accumulating it
- Never use proprietary systems where the knowledge domain is restricted as it would become harder to service in long run due to impending resource crunch over time
Bit rot technical debt
Bit rot tech debt happens over a longer period of time. A system slowly devolves into unnecessary complexity through lots of incremental changes, often exacerbated when worked upon by several developers; who might not fully understand the original design. Symptoms are, among others, copy-paste and cargo-cult programming.
Sometimes we customize our dependencies restricting its domain knowledge to initial resources and over time it would harder and harder to upgrade and backport with the original dependency system. This could spell disaster in the long run if go unchecked over time.
Over time, resources also come and go, making already restricted domain knowledge to rarer. In some time, you may have no resources having knowledge of changes to original dependency
How to address
- Avoid making direct changes to the dependency system
- Make a superset instead of making a subset
- Upgrade the dependency system as soon as possible
- Replace the dependency system that is not actively maintained
Thanks for reading thus far. Please follow to keep watching this space
About The Author
I am Pankaj Baagwan, a System Design Architect. A Computer Scientist by heart, process enthusiast, and open source author/contributor/writer. Advocates Karma. Love working with cutting edge, fascinating, open source technologies.
To consult Pankaj Bagwan on System Design, Cyber Security and Application Development, SEO and SMO, please reach out at me[at]bagwanpankaj[dot]com
For promotion/advertisement of your services and products on this blog, please reach out at me[at]bagwanpankaj[dot]com
Stay tuned <3. Signing off for RAAM