Carry-on codebases

Travel lighter to go faster

Devs love speed, which is why we’re obsessed with benchmarks and Rust. But speed is not just about acceleration; it’s also about mass.

So what’s the heaviest part of our codebase?

Dependencies.

In other words, other people’s code that we rely on to make our code work. GitLab’s 2024 survey of 5,000 DevSecOps pros claims that over 25% of the code devs work on is from open-source. Those guys are either working on CLIs or lying. My calendar app’s codebase has 10 million lines. I only wrote 116,351 lines — just 1.2% of the product. The other 98.8%? Other people’s code.

These numbers are insane, but not anomalous. Web apps are especially bloated these days. This is why we should spend less time looking at the speedometer and more time looking at the scale.

Dependencies are weight

Every dependency adds weight. The more you carry, the more every step costs, and the slower you move. Using minimal dependencies is like traveling internationally with a backpack. You might be going to the same destination as your buddy who brought two suitcases, but you’ll have vastly different experiences.

Let’s start with the heavy traveler, the one who has a “checked” codebase. What is his life like?

Checked codebases

The repo started small and grew quickly. Each dependency felt like a good idea at the time. Of course, you need an HTTP client (even though it comes with a bulky logger). Of course you need that component library with strong opinions about theming (even though you’ll only use five of its components). Of course you should start with $FRAMEWORK_THAT_EVERYONE_IS_USING.

He started with a lot, added more along the way, and never stopped. The PMs were eager to add features, and no one slowed the sprawl.

Now the builds take forever, no one understands why half the packages are there, but they’re all too afraid to do anything about it. So instead of simplifying globally, everyone optimizes locally. He’s greasing the wheels of a 50-lb suitcase instead of taking out the 10-lb boots. He optimizes, but he’s still big and slow.

Traveling with a checked codebase is exhausting. It takes a lot of planning to do a little movement. Each implementation step is also laborious, as he has to check so many surfaces for downstream bugs. He’s forced to bring a month’s worth of clothes for a short weekend getaway hotfix. By the end of the trip, he’s more exhausted than when he left.

Carry-on codebases

The minimalist is initially scoffed at as a simpleton, an irresponsible kid unprepared for the prod life. He sticks to what works, fights complexity vigorously, and has enough clout to be trusted. As a result, his dependency tree is minimal. Everyone knows what every package does. Sure, some teammates grumble about how a modern tool would be faster. But, on the whole, things are working. The builds are fast enough, newcomers can understand the code in days instead of weeks, and things get shipped.

Traveling with a carry-on codebase is chill. A POC gets demo’d. Builds pass. Merged. Done. There are fewer hotfixes, patches, docs, and meetings. The trips to Featureville actually feel energizing, and the team looks forward to the next experiment.

When the requirements change, it’s easy to recalibrate and move forward. Coding here feels like freedom. Not from bugs or feature creep, but from the weight that used to make overcoming those challenges so draining.

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies should be minimal to ease maintenance.
— Bjarne Stroustrup, inventor of C++

The reality of travel

Traveling light has become even more important recently, because travel itself has remained complex. While the vibe coding narrative promises to collapse the SDL into a one-shot prompt, we know that there are still many steps to shipping real products.

Pull → install deps → run tests → wait for CI → deploy → retest → get design feedback → get PR feedback → repeat → deploy to prod → fix bugs → write docs.

The journey is long. At every stage, a heavier dependency graph adds time. Moreover, the dependencies themselves require attention.

We still need to upgrade them. This is like replacing a backpack with a hole at the bottom with a new one.

We’ll need to swap heavy deps for alternatives. This is like swapping a heavy cotton sweater with a light dry-fit one.

We’ll still need to remove third-party libs with built-ins. This is like leaving your glass tupperware at home when you learn the hotel provides some.

Like it or not, dealing with dependencies is still part of our lives, which means it’s still helpful to learn how to pack lightly.

A small dependency graph will not make your product automatically great. But it will make the product easier to build, easier to understand, easier to debug, and easier to adapt when reality changes.

A light traveler is a fast traveler.

Story from the road

I fly with this backpack instead of those rolly carry-ons that real adults use. It fits overhead and underneath. It lets me take the stairs at the hotel when the elevator line is long. It helps me blend in at a coffee shop. When the ski lifts shut down, it allowed me to haul my gear to the top for one last run. My fancy shoes don’t fit, which means I lose some fashion points. But I gain so much speed and lightness. Once you feel that freedom, it’s hard to go back.

---

More

On the Relationship between Software Complexity and Maintenance Costs (2014).

Software complexity and maintenance costs (1993) | Analyzes Cobol maintenance projects in a large commercial bank.

Software Dependencies, Work Dependencies, and Their Impact on Failures (2008) | How dependency measures relate to defects.

DevSecOps Report: Application security in the digital age (2024) | GitLab’s survey

Do you think traveling light is always better, or are there exceptions?