A Discussion of Good Technical Debt with Jon Thornton | SimpleLeadership Podcast

‌

Episode description

‌

Episode description

Jon Thornton worked at some small companies in NYC before he ended up at Squarespace. He’s been able to build a new product and new team—their email marketing product. He launched that and has since been supporting other products. Throughout his career, he’s learned how to manage technical debt. What is the difference between technical debt and good technical debt? What is a framework for using technical debt? Listen to this episode of Simple Leadership for Jon’s advice on managing technical debt.

Jon has been solving problems with software for over 20 years and leading engineering teams for 10. Along the way, he's parked millions of cars, improved textbooks with AI, reduced the price of prescription medication, and sent billions of emails. Currently, he's an engineering director at Squarespace in New York City. Though Jon's day job is mostly meetings and documents, he still gets his coding kicks in by maintaining a mildly popular jQuery plugin in his free time.

[1:26] Jon’s history in programming

[4:43] Mistakes Jon made early on

[6:22] What would he have done differently?

[7:32] Teamwork isn’t about individual output

[8:25] Financial debt and technical debt

[10:53] Why time is currency

[14:32] Good technical debt is intentional

[17:14] A framework for using technical debt

[21:24] Why building trust with your team is important

[22:37] Jon’s book + podcast recommendations

[24:54] How to connect with Jon

The common definition of technical debt is that it’s code that you don’t like and you’ll need to fix or change later. But Jon applies a more narrow definition: It’s work that he expects to have to do in the future. It’s not necessarily code that he doesn’t like.

Jon points out that financial debt is a commonly accepted occurrence. Someone that takes out a mortgage to buy a house and is congratulated. It’s a “responsible” use of debt. You can use technical debt to get value now and then you can pay it down over time. It’s a tool. It allows you to reorder when they value and the payment happens—you just have to use it responsibly.

People want to have perfect code from the moment of conception, but it isn’t always worthwhile from an ROI standpoint. If it doesn’t make more money or provide more value, it can be shelved for later.

When you think about starting a new engineering project, it starts with estimates: “How much is this project going to cost us?” It typically refers to man-hours or engineering week. The cost of the project is how long the team will spend building it. If you’re following the financial debt analogy, you are taking out a tech debt mortgage. You’re borrowing time that will be paid back later. You’re doing it in a way that creates more value now.

The main reason engineers exist is to provide value—to shareholders, your company, and the users of your product. If a manager takes over a team from another company, they’re immediately taking on technical debt or risk that has accumulated. How do you walk through that? How do you evaluate that?

According to Jon, you can talk to people or read commit history to understand how you ended up with the system you have. The next step is to assess the kind of technical debt you’re dealing with. What technical debt is actively accruing interest? Are you spending time on it with bug fixes? Is it growing larger?

There may be an API with design issues. If you keep building on top of it, it will be harder to evolve later. Other kinds of debt may be a scaling issue where performance is okay now, but your database can’t support it later. You have more time to put that technical debt aside and address it later. Assess and establish urgency.

During his initial Squarespace project, Jon used an access control list where only certain people had access to certain features. The right way to build it is to have a database table and management UI that makes it easy to add people. But the list didn’t change frequently. It would be easier to have a hard-coded list of IDs in their code-base. To give someone access, they’d make a new commit and deploy it. It was fine for the first two years of the project. They’d instead spend their time on things that immediately impacted the project they were working on. They could go in and make the list more dynamic down the road.

Jon recommends that you do the riskiest parts of your project first. Reordering the way you build things enables you to tackle risk first. With any project, there's usually going to be some problems that you have to solve that are going to make or break the success of that project. You want to figure out those things as soon as possible so you have time to deal with any consequences. Managing a list wasn’t going to make or break their project. But the email editor they were building was going to make or break it, so they spent time on that first.

Jon’s techniques for managing technical debt (scaffolding, hard-coding, edge cases, etc.) are all based around the idea of accepting that it’s okay to build something twice. That can help you reorder the way in which you build things. Scaffolding is inspired by physical buildings. Sometimes while you’re building one structure, you need to build a temporary structure (scaffolding) to support what you’re building. You’ll eventually take it down and replace it with something more permanent.

They knew they needed the capability to send billions of emails, but they didn’t need that capability to test the email editor that they were building. They needed to build the editor before building the sending capabilities. There was less innovation to solve there. So they built something unscalable that allowed them to test the editor first. They knew they would build the delivery pipeline twice. It had value.

How do you show that technical debt is deliberate? How do you get stakeholders on board with the technical debt? Why is trust so important? Listen to the whole episode for the whole story on technical debt.