DEV Community

Arpit Mohan
Arpit Mohan

Posted on • Originally published at

Big myths surrounding technical debt

TL;DR notes from articles I read today.

Five big myths surrounding technical debt

  • Myth #1 is that tech debt is amorphous, when in actuality it is usually a collection of many discrete problems. This means you can quantify tech debt (frequency, impact, cost to fix) on a spreadsheet or tracker and then prioritize based on impact.
  • Myth #2 is that all tech debt has a single cause. In fact, there are three major sets of causes (or enablers):
    • Intentional tech debt, where the team knowingly took shortcuts to meet deadlines.
    • Unintentional, where poor code results from inexperience or incompetence or misunderstood requirements.
    • From age, where incremental enhancements and bug fixes cause a bit rot.
  • Myth #3 is that you should never intentionally take on tech debt. But there are three situations where it may be justified: you are building a prototype or demo module to solicit feedback on a new feature or product, time to market is critical or you are building based on guesswork and anticipate client requirements will change sooner than later.
  • Myth #4 is it only hurts engineers. In fact, it affects developers, product managers, customer support teams and customers, technical operations, and any executive team you may set up.  
  • Myth #5 is that only a full rewrite can repay the debt, whereas more often, a detailed plan of incremental fixes will solve it.  

Full post here, 8 mins read

Indirect benefits of building API-first

  • A major benefit of building API-first is agility, both digital and strategic. You are not constrained to a single usage pattern and have the basis for a variety of applications with use cases you can’t even imagine yet, offering both flexibility and reusability.
  • Your end-user has a better experience since APIs encourage interactivity across internal and external applications, creating a stickier, unified experience for consumers.
  • Building your organization around APIs creates a potential for partnerships, big and small, whether using the marketplace model (your platform allows others to build and distribute custom add-ons, in turn extending your own platform) or one where partner APIs share data with a common, collaborative goal.
  • Outward-facing APIs enable the growth and inception of self-sustaining developer communities, providing you with awareness, API support, product suggestions and more.

Full post here, 4 mins read

Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().

Top comments (0)