Why is this interesting? - The Technical Debt Edition

Noah here. This week Evernote released a new app for Mac and Windows. In our current software-centric universe, that’s not a particularly notable thing except for the fact that the company has essentially pushed out no new functionality for 18 months—an eternity in the world of tech. The note-taking app/company had once been a darling of Silicon Valley, but it struggled as it aged and new upstarts like Notion came along that swept up attention and users. As I’ve noted in the past, I’m a fairly serious Evernote user, with nearly 20,000 notes stored. It’s the backbone of my approach to WITI, allowing me to find interesting articles and papers I’ve read over the last decade.

So what happened over the last 18 months at Evernote? In 2018 the company brought in a new CEO who decided the most important thing to work on was cleaning up the many layers of cruft the codebase had accrued as they chased growth. With that they decided that rather than building new features, they were going to go back and fix up all the old ones, no matter how long it took. Here’s how CEO Ian Small described it in a recent interview:

Somebody internally described it as, what we're doing is we took a huge breath, we dove underwater, and now we're swimming. And the longer we're underwater, the more our lungs are burning, and the harder it is, but we don't get to come up until we're done.

That's absolutely what it feels like on the inside. We know that there's a tremendous demand from our users for us to move forward. We know there's real problems in some of the apps that are out there, both architecturally and from a standpoint of bugs and from a standpoint of consistency.

Why is this interesting?

If you work inside tech—and maybe even if you don’t—you’ll recognize the pattern of built up cruft around a software product as technical debt. Tech debt is something accrued when code is written in a suboptimal way. It was originally coined by programmer Ward Cunningham in a 1992 report:

Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.

You build debt in your codebase for any number of reasons, most notably taking shortcuts and not understanding the problem to the extent you will in the future. That debt builds if you don’t start to “pay it down” by going back and fixing (refactoring) the code. Eventually, as Cunningham explains, unpaid tech debt starts to slow down all other work as you have to continually deal with a history of poor decisions and implementations. According to McKinsey, CIOs report that 10 to 20 percent of their technology budget is devoted to dealing with issues related to tech debt (which, in my experience working with big organizations, seems like a low estimate).

Evernote’s approach is admirable, but also extreme. For better or worse, few companies can afford to give up pushing the ball forward for a year-and-a-half to fix issues of the past. The problem with that logic, of course, is that the more you ignore it, the more it builds up and becomes impossible to ignore. Finally, lest it feels like this is purely engineering-centric, the analogy of debt is applicable across all kinds of organizations and work output. Company cultures build debt in the form of outdated ideas about what’s important and the processes for getting things done. Governments build debt in the form of policies built on top of other policies that are no longer performing their function. 

One way of avoiding debt like this goes back to February’s Maintenance Edition and Vaughn Tan’s ideas of maintenance by design:

One more step beyond that is thinking of maintenance as a way to trigger unexpected ways of looking closely at a complex system—maintenance as investment in nonparameterized system awareness. A daily yoga practice is a form of maintenance, as is a weekly stand-up project team status meeting, or a quarterly board meeting for a startup. Doing the same thing at a regular interval provides opportunities to recognize when the system is beginning to fray in ways that simple problem-finding wouldn’t catch.

In addition to being aware of the debt and making good upfront decisions, building structures around those decisions that ensure ongoing maintenance—of code, culture, and even bodies—can ensure you don’t end up over your head in metaphorical debt. (NRB)

Flowchart of the Day:

WITI contributor Anita shared this map of Disney’s business from 1957 (which she found via Aja Singer).

Quick Links:

• Big Veg Twitter is the last corner of the internet that is wholesome and good (NRB)

• Good one from Wirecutter: Why Your iPhone Has So Many New Privacy Alerts in iOS 14 (NRB)

• Great piece from the NBA site Cleaning the Glass on the fundamental attribution error. Good for basketball and non-basketball fans. (NRB)

Thanks for reading,

Noah (NRB) & Colin (CJN)

PS - Noah here. My company, Variance, is looking for a lead product designer (remote) to join the team. If that’s you or someone you know, please be in touch.

—

Why is this interesting? is a daily email from Noah Brier & Colin Nagy (and friends!) about interesting things. If you’ve enjoyed this edition, please consider forwarding it to a friend. If you’re reading it for the first time, consider subscribing (it’s free!).