Tech Debt Burndown Series 1 E1: What Is Tech Debt?

Tech Debt Burndown Podcast

What is technical debt? Nick and Chris offer their definitions, despite agreeing there is no right answer.

Recording date: December 6, 2020

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

Nick thinks it is the stuff we put off in favor of things we want to do*, while Chris quotes Ward Cunningham and Martin Fowler, summarizing that technical debt is basically the quick and dirty fixes that incur interest payments, and using the concepts of tech debt to describe problems faced over time.

A chat about “shift left” or moving earlier in the SDLC, which boils down to the human factors of tech debt accrual.

Nick mentions a collection of moments in which decisions are made to do the scalable thing or do the fun thing. Chris points out these concepts apply to both Waterfall and Agile approaches, and invokes Paul Downey in his discussion of when decisions get made and how they are addressed.

When should it be addressed? Why do organizations schedule huge tech debt burndowns as opposed to building in TDB to every sprint (Nick quotes, but forgets to credit, Ian Amit, and this quote is covered in Episode 2), and Nick quotes Phil Venables who tweeted that we should measure tech debt in the terms of what percentage of dev time is spent on this.

Which leads Chris to ask about what metrics are right. How do you calibrate information about doing it quick versus doing it right?

How hard are these problems?

From engineering time to executive buy in, these are critical issues. We can’t tell you the monetary value of not scaling a thing, and that is a huge issue.

• Audits are asking about technical debt and related issues. The questions are getting harder.

Chris mentions that one if the issues that arises is what kinds of tech debt do we face? One of the ones he likes to focus on is policy debt, which is a fundamental type organizations face.

This raises the issue of policy over time: in FinServ, most policies were written in the days of the moat and the gate, and they don’t address contemporary, cloud native architectures.

This brings in some of the human decisions we make.

How do we answer questions about the interplay between policy and regulation, like the “should we reset our passwords every 90 days” question.

Chris summarizes the three different global approaches to regulation.

• Singaporean: very prescriptive.

• Anglo-American: Principle based, broad brush of expectations and relying on audit companies

• Swiss: More comparative: an expectation of participants in the marketplace to reach a certain standards.

Nick describes how US auditors are asking more about technical debt management, but they’re not getting highly specific enough to differentiate betwen tech debt and the underlying policy debt which might drive it.

When we told auditors that our main goals in security was to get rid of tech debt and the auditor asked whether I meant ‘security tech debt’ or just plain old ‘tech debt’ - what’s the difference?

Chris then discusses the CIA triad and talks about how we in Information Security seem to have abdicated the ‘Availability’ part, then referred to a 2006 report called Milk or Wine: Does Software Security Improve With Age which is very pertinent.

The discussion moves to tests: is there a vulnerability in the code, but the bigger aspects of debt include such paralysis that they can’t change anything, because they don’t have the test coverage to know whether a fix here will affect something unintended there?

So test coverage and testability must be part of a strategy to address tech debt.

We in the industry are constantly talking “secure by design,” “shift left,” and the like, but what does this mean in practicality? So, if we are starting a software project today, what are we going to do differently now from last year?

Nick describes his firm’s Squad Security Liaison program, which is designed to foster inter-disciplinary teamwork by making introductions between engineers and security people on a regular basis, to encourage interaction and collaboration. It means they know one another before problems exist, so relationships are there when something goes wrong.

This podcast is all about learning!

---

* Wendy Nather disagrees with “want”.