How 4 NYC Companies Measure and Manage Technical Debt

by Janey Zitomer
October 7, 2019

We’ve all heard stories about that friend from college taking unnecessary layovers to accrue miles. 

Just as gold preferred status might be worth a few late-to-the party entrances, unoptimized code is often the price engineers pay for ultimate software success. Sure, Joe might have the middle seat now. But we’ll see who’s laughing next summer. 

We spoke to four NYC employees about why code often piles up, and how they manage and minimize it. 
 

Squarespace employee Jackie Benowitz
Squarespace

It should surprise no one that when describing technical debt, Jackie Benowitz, Squarespace senior software engineer, relies on a well-known theory of statistical mechanics/thermodynamics. After all, Squarespace’s mission is turning complicated back-end systems into simple, elegant visuals. 

We spoke with Benowitz about why, like entropy, technical debt increases over time and what their team does about it.  

 

What is technical debt and how does your team define it? 

Technical debt is the cost incurred when you prioritize factors like speed to market over building perfect solutions. Technical debt occurs similar to entropy. It accumulates as product decision changes and/or evolves. These costs include but aren’t limited to tangled code, unhandled edge cases and error states, and increased time maintaining and onboarding new developers to the system.

For example, we needed to prioritize iterating quickly as we wrap up a yet-to-be-released product. As a result, we decided to migrate off GraphQL for our API contract and use REST instead. Since deciding on GraphQL, our product has changed drastically. The aggravation it caused us did not outweigh the onboarding costs, iterating costs, and lack of out of the box observability REST APIs have here at Squarespace.

Technical debt isn’t necessarily measured on our team, but rather prioritized.’’ 

 

When technical debt does occur, what process does your team use to measure and manage it?

Technical debt isn’t necessarily measured on our team, but rather prioritized. During retros and milestone whiteboarding sessions, we work together to raise the important pain points and weigh what needs to be addressed immediately. Often, these larger debt payments are added to our sprints and estimated exactly like a product task. 

Inspired by the campaigns team, we’ve dedicated one day per sprint to tackle tech debt any engineer wants to address. We continuously evaluate whether to address tech debt now or later. We constantly ask whether paying down some tech debt is worth pushing back our release date.

 

What proactive measures does your team take in minimizing technical debt?

Due to managing past tech debt, we’re now looking at building features in a new light. Before jumping into features and larger tech debt payments, we write out technical implementation plans as RFCs (review for comments). RFCs allow us to propose ideas clearly while getting ideas from reviewers. This helps expose possible debt we’re taking on, but historically track the decision of why we’re OK with that.

We’re constantly juggling what’s the right technical decision and what can we do right now to create the feature fast. These RFCs help answer questions we ask ourselves every day. What are the tradeoffs for doing the faster path? What small changes can we make that won’t keep us drowning in tech debt in the future? A lot of times, especially nearing the finish line of a project, taking on tech debt has a high reward, and that’s OK!

 

Quartet health team meeting
Quartet Health

Not having technical debt doesn’t mean you’re beating the system. Rather, it means you’re potentially not producing code quickly enough or iterating as necessary. Brad Moore, vice president of engineering at Quartet Health, gave us a few examples of situations where technical debt might surface as part of the overall process.

 

What is technical debt and how does your team define it? 

We think of technical debt as the backlog of work created whenever we do not achieve a desired quality standard on our engineering delivery. It may be the result of a deliberate compromise or an unforeseen side effect of a decision. As it accrues, technical debt results in higher costs of maintenance and enhancement.

An example includes code that might exceed a desired level of complexity (meaning the code performs exactly as specified, passing all tests), but is expensive and risky to maintain over the lifecycle of the product. Another example is code has a dependency on a third-party library version that is currently end of life. In this case, the code performs as expected but the third-party library must be upgraded to ensure ongoing support.

It may be the result of a deliberate compromise or an unforeseen side effect of a decision.’’

 

When technical debt does occur, what process does your team use to measure and manage it?

At Quartet, technical debt is managed in a backlog just as we manage product features. Most importantly, our engineers transparently communicate our technical debt backlog to product management, so that it is prioritized.

 

What proactive measures does your team take in minimizing technical debt?

You can minimize unintentional technical debt by taking steps to prevent it from happening through good engineering practices such as reviews, static analysis, and training. Regardless of what prevention is in place, technical debt will still accumulate. It’s most important to continually work on paying down the debt to keep the code healthy. This requires continual negotiation between engineering and product management.

 

Zipari team photo
Zipari

When it comes to technical debt, Zipari understands the importance of making the right kind of compromises. Jyoti Mokal, VP of consumer engagement products at the technology company, told us about how they believe openly talking about critical code requirements improves the process from beginning to end. 
 

What is technical debt and how does your team define it?

Technical debt describes the costs of future work created by making coding choices to deliver working product in the short term. It’s the reality of coding. Whenever you code a product, you are faced with constraints, including time, resources, and what’s known and predicted about user interaction. For example, when there is a time constraint, engineers must make compromises, choosing to write simpler pieces of unoptimized code. This, in turn, produces technical debt; time and resources that will be owed following the initial production completion.

Our leadership understands that writing code against a deadline requires compromises.’’

When technical debt does occur, what process does your team use to measure and manage it?

A finished product with no technical debt would be, by definition, perfect in every functionality, every use case. This is simply impossible. Technical debt occurs in every software development process. You can measure it by tracking what has been prioritized for completion and anticipated needs after initial production. At Zipari, we manage our tech debt by encouraging our engineers to talk about it in the open. As long as engineers meet our customers’ most critical requirements, they are empowered to build technical debt into products, record it, and keep moving toward deadlines. That helps ensure we make production timelines and enables us to schedule debt pay-back, so we can manage evolving product priorities.

 

What proactive measures does your team take in minimizing technical debt?

At Zipari, our engineers know that accruing this sort of debt is normal and necessary. The key is to track it and keep it under control. Our leadership understands that writing code against a deadline requires compromises. Documenting that debt shifts the perception that technical debt is a sign of sloppy coding and creates a shared understanding of immediate and longer-term costs and benefits to technical choices. This reduces the pressure for engineers to hide their debt and reduces the chance for bugs, broken products, and unhappy clients.

 

Paperless Post presentation
Paperless Post

Engineers like Udi Pladott know that when it comes to software programming, updates and installation, if you’re not ahead you’re behind. But when foundational data programs mature in the equivalent of dog years (ie. quickly!), it can be impossible to maintain compatibility. Pladott explained how online invitation company Paperless Post handles tech debt and optimizes for the future. 

 

What is technical debt and how does your team define it?

Technical debt is any development work that is in our backlog as a result of either conscious, calculated shortcuts we took while developing and delivering more urgent product functionality, or as a result of engineering oversights that were identified after the code was deployed to production. For example, we built our product on a particular version of an open-source or third-party library (e.g. Ruby on Rails 4.x) and then continued developing our code without devoting the necessary time and resources to keeping our code compatible with version updates of that external library. As a result, at some point, our product will be running on technological foundations that may be several years old.

 

When technical debt does occur, what process does your team use to measure and manage it?

Any technology company that has been around for several years will incur some technical debt. We are no exception. To deal with our own tech debt, every sprint, each team dedicates at least 10 percent of its time to working on issues that are not on the front line of its feature development and bug-fixing objectives. A lot of this is about technical debt. However, some tech-debt tasks may be too large or complicated to address in one sprint, so a team may take on some pieces of debt as long-term projects, breaking them down to sprint-size iterative steps. 

Any technology company that has been around for several years will incur some technical debt.’’

What proactive measures does your team take in minimizing technical debt?

The best way to avoid tech debt is to write good code. No code makes its way to production without peer review. However, our goal isn’t to categorically avoid technical debt, but to be smart about how much of it we take on. If we take a shortcut so that we can get a product out and start learning about it faster, we’ll think about how quickly we’ll need to pay back that debt and how much harder it will be to do that work down the road. We try to think through complicated projects collectively in order to come up with the optimal solutions, balancing the speed of development with the long-term sustainability of the code.

 

Jobs from companies in this blog

NYC startup guides

LOCAL GUIDE
Best Companies to Work for in NYC
LOCAL GUIDE
Coolest Tech Offices in NYC
LOCAL GUIDE
Best Benefits at NYC Tech Companies
LOCAL GUIDE
Women in NYC Tech