Features ↔︎ Tech Debt Tradeoffs

This is a bit of old news at this point, but I can’t help but be amused by this retelling of a small part of the ongoing Twitter drama:

For context, what was happening here was that Elon was holding a townhall-esque Twitter Space talking about the engineering behind Twitter’s systems—when it’s been proven repeatedly that he doesn’t know what he’s talking about. The host, Geohot, is a programmer who became famous for jailbreaking the iPhone and PS3 and founded an early self-driving startup. He took a 12-week “internship” at Twitter when Elon acquired it to fix search, but ended up resigning on the day of this Space meeting citing that he couldn’t make enough impact.

On one hand, this is an expected and foreseeable outcome: an engineer with a hacker mentality joins a big company with a large1 engineering team and realizes that building at scale requires a different skillset than throwing code to get something cool working. Everything takes more process and effort than they’re used to, it gets denounced as needless bureaucracy and the engineer leaves in a huff. It is the epitome of not being able to scale to the organization.

But on the other hand, this impasse is more about making tradeoffs between product delivery and technical improvements, i.e., tech debt. Most of the time, at least within engineering circles, the problem is framed as not enough time spent recognizing and fixing accumulated debt2. The other side of this tension is working on product and features, which tend to impact more directly against business goals and objectives.

These two areas aren’t directly comparable! A large part of what creates this tension and why it’s so hard to resolve cleanly is that they operate on different time scales, or are at different levels removed from business: features can tie directly to business metrics, but tech debt streamlines future product development as well as mitigating future potential issues. It also turns out that each type of work attracts its type of engineer, some who like being at the forefront of product development while others enjoy crafting the underlying frameworks and architecture. Most engineers end up doing both at some point in their careers or as the team needs, but pretty much all the senior engineers I interview and work with express personal preferences in a particular direction, even if it’s to change up what they did at their last job.

Counterintuitively, I find the less experienced engineers are the ones who insist on major refactors and weaving new frameworks ex nihilo3 than more seasoned folks. Some of it holds to the cliché of not wanting to read others’ code, but it’s the lack of understanding of business needs and how it drives prioritization. As most developers eventually figure out, business value creates the need for code, which is also most likely why and how we’re paid as developers. A definition of maturity I use for software engineers is the ability to address increasing complexity with solutions—not software complexity, but business ones.

Which sometimes means that you can’t stop the world to refactor the codebase when the company needs to ship to keep itself solvent4.


  1. Well, it used to be large before the layoffs and resignations.

  2. My friend and former colleague Jack Danger has a great framework to think about technical debt.

  3. Moreso on front-end web development, anyway.

  4. Of course, whether it’s as dire as Elon was stating here has to be taken with a grain of salt.

Share this article
Shareable URL
Prev Post

Breaking Up the Twitter Monolith

Next Post

Verticalizing the Automotive Industry

Read next