Startups Do Not Need To Take On Technical Debt

You don’t have to take on technical debt as a startup.

Over the decade, I’ve been part of a variety of startups that have a giant monolithic codebase, full of technical debt — code that is hard to change due to poor test coverage and poor architecture, with files and functions that are thousands of lines long.

People often ask me, “How do we balance moving fast with writing good code?” The thinking seems to be that, when building out a new feature (inevitably, on a time crunch), the only way to go is to write spaghetti code. This framing is a false dichotomy.

In some cases, it is a knowledge/skill gap. For an engineer that understands modularity and coding best practices, writing “good” code does not have to take longer than writing spaghetti code. Does adding new code in a separate module or function take any more time than inlining that logic in an existing module? Not really. The engineer that hasn’t learned the value of modularity and the techniques for implementing it might simply default to adding lines to existing files, until a huge mess appears. The engineer that has no experience with test-first development will find it easier to simply skip writing tests.

To some extent, there may be a leadership gap as well. There may not be a senior engineer, reviewing the code, and guiding the team towards these better practices. Or engineering management may be feeling executive pressure to deliver now now now, and that pressure may translate to engineers feeling like they have to write bad code.

The saddest part of all of this is that over time, this technical and leadership approach leads to the team executing much slower, as unpaid technical debt accumulates.

What can you do?

If you’re an engineer, writing clean code is a skill, so learn it. There are numerous resources online, and it is an incrementally applicable skill. If you are a leader, make sure your team is staffed with at least some senior engineers who can guide the architecture and mentor others on writing maintainable code. Leaders should also make sure the team understands that the company values the long-term ability to maintain and evolve the code.

For a deeper dive into tech debt, including when it might make sense to take on debt, read Avery Pennarun’s tech debt maximalism post.

This is a lightly edited version of a LinkedIn Post.