Technical Debt

I recently wrote a post on CloudRail API Integration Solution‘s blog about Technical Debt. Technical Debt is a metaphor often used to describe the consequences (price, developer hours etc.) of choosing a quick and easy solution, which eventually has to be refactored or replaced.

Let’s say you use a 3rd party library to save time, and ship the product faster, instead of designing and coding the feature from scratch. Then you are taking on technical debt, and how much depends on how much time is spend adapting your product to the library.

One of the things I talk about in the post is, that sometimes the technical debt, and the interest of the debt, can be so low, it doesn’t make sense to refactor or replace the code with your own. I’m very much against looking at technical debt as something negative by default. As long as it’s calculated and managed in a proper way, taking on technical debt can make a lot of sense.