#tech debt
6 posts

Manage technical debt: How to shine a light on issues in your code base

This post likens accumulating technical debt to financial debt. There are nuances to this metaphor but it helps us visualize and understand technical debt.
Read more

Manage technical debt: How to shine a light on issues in your code base

This post likens accumulating technical debt to financial debt. There are nuances to this metaphor but it helps us visualize and understand technical debt.

  • Technical debt is accrued because of the changing nature of software products. Since software is a virtual system, most users don't know what they want till they see an initial version. After that point, modifying the codebase is like building a skyscaper on the foundations of a 2 storey-house.
  • Symptoms of technical debt include: bugs, performance or quality issues, speed of feature delivery, burnout in the team. Keeping an eye out for these symptoms helps us bring the issue to the forefront.
  • One suggested way to reduce technical debt is to keep swinging between feature addition and software improvement. This ensures that the software always has some breathing room for growth.
  • Notice the symptoms and allow the engineering team to front-load the cost of fixing the issue. For example, if the ops team is awake most nights, instead of adding a new feature, work towards fixing the root cause of their nightmare. This builds a culture of quality-first.
  • Technical debt is everyone’s problem, and once you surface the issues, fixing them is far easier.

Full post here. 7 mins read

Is High Quality Software Worth the Cost?

The trade-off between quality and cost doesn't exist in the software world. Counter-intuitively, higher quality software tends to be cheaper in the long run. This article explains how to put quality, cost of ownership and technical debt into perspective.
Read more

Is High Quality Software Worth the Cost?

The trade-off between quality and cost doesn't exist in the software world. Counter-intuitively, higher quality software tends to be cheaper in the long run. This article explains how to put quality, cost of ownership and technical debt into perspective.

  • Software quality is divided into external (can be seen by the user) and internal (code architecture).
  • Internal quality, even though invisible, makes is easier to enhance the software and push releases much faster. The cost of adding a new feature or fixing a bug is termed as technical debt.
  • High quality software always pays an initial upfront cost in order to get the code architecture or design right. Over time, the ROI on a well designed codebase is much higher.
  • The best software teams end up creating technical debt. This is largely attributed to developers never solving a new problem with each product. To deal with this cruft, great teams write automated tests and continuously refactor to fix issues, keeping it at a manageable level.

Full post here. 14 mins read

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 on a spreadsheet or tracker and then prioritize based on impact.
Read more

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):

a) Intentional tech debt, where the team knowingly took shortcuts to meet deadlines.

b) Unintentional, where poor code results from inexperience or incompetence or misunderstood requirements.

c) 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

The wall of technical debt

Use a physical wall to visualize your tech debt on sticky notes. It is easy to start and maintain, yet it can usefully impact choices that add, payback or ignore the technical debt.
Read more

The wall of technical debt

A method to make technical debt visible and negotiable:

  • Use a physical wall to visualize your tech debt on sticky notes. It is easy to start and maintain, yet it can usefully impact choices that add, payback or ignore the technical debt. Pick a central location with high visibility. Make the display dramatic.
  • Decide on some sort of tally mark to represent costs (time or money), so it is not a matter of opinion only. Conversely, if it does not have a cost but only looks awkward, don’t log it as debt.
  • Build a working habit and stay honest
  • Keep your notes short but easy to understand - what made code difficult to understand, what slowed it down, why a bug was hard to find, what should have been better documented or tested. Estimate the opportunity cost as well as time to fix the issues. If your team is using an issue tracker, add the ID to the sticky notes.
  • Negotiate tradeoffs based on this visualization. Discuss as a team whenever someone needs to add a note or time notation whether it is faster or cheaper to fix the debt. If it is, fix it right there and then. If not, add it to the wall. Give away control to managers to decide what to focus on.
  • Beware of starting with a complete debt audit - it can become its own bottleneck as it calls for buy-in and tends to get put off indefinitely.

Full post here, 7 mins read

How to minimize security debt from the start

Take stock and build an inventory of all connected devices and applications within your network, locate where all data reside, and audit access to them. Secure data travelling within as well as across networks.
Read more

How to minimize security debt from the start

  • Retrofitting security issues requires that you refactor not only code but also human behavior.
  • Take stock and build an inventory of all connected devices and applications within your network, locate where all data reside, and audit access to them.
  • Secure data travelling within as well as across networks.
  • Take special care to secure DevOps projects as they introduce considerable security risks.
  • Establish an access management policy that evolves as your organization grows.
  • Encrypt data (in rest and in motion), use multi-factor authentication, ensure redundancy, and segment data and systems.
  • Build a good incident recovery plan right from Day 1.

Full post here, 5 mins read