Name: Big myths surrounding technical debt
Rating: 4.9 (1624 reviews)
Author: mohanarpit

TL;DR notes from articles I read today.

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

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