Good Things Come In Small

Why Smaller Code, Smaller Tools, Smaller Everything Usually Wins

I used to build projects with massive dependency trees. Three years ago I was shipping a Python data pipeline that required twelve packages just to parse a CSV and write to a SQLite database. The environment setup alone took twenty minutes on a fresh machine. Somewhere along the line I noticed the most reliable parts of my workflow were the ones that did less. That observation turned into a habit, and the habit turned into something I now call Good Things Come In Small. At its core the principle is simple: when you strip a system down to its essential function, you expose the points where things actually break. Bloat hides bugs. Bloat masks design flaws. A hundred-line script with no dependencies will fail in a way that teaches you something. A thousand-line monolith with fifty third-party packages will fail in a way that sends you digging through six layers of abstraction you didn't write and don't understand. I learned this the hard way on a production job last year. We had a monitoring daemon built on Node with a framework layer, a templating engine, an HTTP server, and a message queue client. It ran fine in staging. In production it would occasionally deadlock under low memory conditions because the event loop was starved by unbounded callback queues from three different npm packages that all listened to the same socket event. The fix wasn't to optimize the Node code. It was to rewrite the daemon in Go as a single forty-five-hundred-line binary with no external dependencies. Deployment went from a Docker container with a 1.2GB base image to a 14MB static binary. The deadlock disappeared. We also cut our CI build time from eight minutes to forty seconds.

That's not a unique story. It keeps repeating with different technologies.

How to Apply the Principle Without Overcomplicating It

Start by asking what the absolute minimum viable system looks like for whatever you're building. Not what your team expects. Not what feels professional. What is the smallest thing that actually solves the problem? Here is the checklist I use before committing to any tool or library: Step one: Can this be done with built-in language features? Python has pathlib, subprocess, json, and sqlite3 in the standard library. Most of the time you don't need Pandas to read a file. Most of the time you don't need Requests if urllib or http.client does what you need. Ruby has Net::HTTP. Go has net/http. These built-ins are boring and they work everywhere.

Step two: If you must add a dependency, pick the one with the fewest transitive dependencies. Check the package tree before installing. In npm that means running something like npm ls. In pip that means looking at the package metadata. In Rust check crates.io dependency counts. A package with four direct dependencies that pull in twenty transitive ones is a liability. Step three: Write the thing manually first. Even if you eventually use a library, writing the core logic yourself forces you to understand the failure modes. I once spent an afternoon implementing a basic LRU cache from scratch before adopting one from a library. The library version had a subtle bug around concurrent eviction that cost me two days of debugging. The manual version had no such bug because I wrote every line. Step four: Measure the actual runtime and memory footprint, not the development experience. A framework might make your first hour of coding faster but your tenth hour of debugging significantly slower. Track deployment size, startup time, and memory usage under load. These numbers don't lie.

Where the Principle Breaks Down

This is where I need to be honest with you because I've seen people take this too far and make worse systems. Good Things Come In Small is not a license to reinvent everything. Writing your own TLS implementation because you don't want to depend on a crypto library is a terrible idea. Building your own scheduler instead of using a battle-tested cron system is usually a terrible idea. The principle applies to the boundary between your logic and the machinery around it, not to well-solved infrastructure problems. Small systems also struggle at scale in terms of feature richness. A thirty-line script that works perfectly for five users will not work for five thousand. You will hit concurrency limits, error handling gaps, and edge cases that only emerge under load. The workaround is not to abandon smallness but to add structure incrementally. Start small. Add one dependency or one module only when you have concrete evidence you need it. Don't preemptively architect for problems that don't exist yet.

There is also a team dynamics problem. If you're working with twelve people who all have different opinions about what the "right" small solution looks like, you'll end up with committee-driven complexity regardless of your intentions. In those situations the constraint isn't technical. It's social. You solve it by limiting decision rights, not by shrinking the codebase.

Specific Edge Case: Configuration Drift in Minimal Deployments

Here is a problem I ran into that most people writing about this topic don't mention. When you go small you tend to favor manual configuration over declarative infrastructure-as-code. A small shell script with environment variables feels simpler than a Kubernetes manifest or a Terraform file. It is simpler until you deploy it to three different machines and spend two days figuring out why the database connection fails on one of them. The issue was a stale environment variable from a previous deployment that nobody remembered setting. The workaround I settled on was keeping the code small but making the configuration explicit and version-controlled. Instead of relying on environment variables I use a single config file checked into the repository, read at startup with validation that fails loudly on missing or invalid values. The code stays minimal. The config stays traceable. The two together replace the illusion of simplicity that comes from spreading assumptions across machines and memory.

Concrete Numbers That Matter

When I switched a personal project from a Django-based stack to a custom Python script using only standard library modules plus one lightweight library for JSON serialization, the results were measurable: The tradeoff was that I spent about three extra days writing code that Django would have generated for me. Those three days paid for themselves in the first month of reduced incident response time. That ratio is typical, not exceptional. When I applied the same reduction to a Rust-based log aggregation tool, the results were starker. The original tool used a custom HTTP framework, a serialization library, and a logging facade. The rewritten version used only std and two crates. The binary went from 48MB to 3.2MB. Memory usage under steady state dropped from 340MB to 18MB. The feature set remained identical. The only thing that changed was what I chose not to include.

How to Know You Are Doing It Right

There are a few signals that tell you whether you've actually achieved smallness or just built a smaller version of the same problem. If you can explain how the entire system works to someone else in under five minutes, you are probably on the right track. If explaining it requires a diagram with four boxes and three arrows, you have more system than you need. If a new team member can set up the development environment in under ten minutes on a clean machine, the dependency footprint is likely reasonable. If setup takes longer than the first commit, you have hidden complexity.

If you can read every line of code in the project during a single workday, you are within the sweet spot. Anything larger than that and the marginal benefit of knowing the full system starts to decline sharply. At that point you need better abstractions, not fewer dependencies. The metric that matters most is incident density. Count the number of production issues per month divided by lines of code or features delivered. Watch what happens when you reduce the system. If the ratio goes down you have found real value. If it stays the same you may have just removed features rather than complexity. I still make mistakes. I still reach for a framework when a script would do. I still add a dependency because the documentation looked promising. But I catch myself earlier now, and the cost of each mistake has gone down significantly since I started treating smallness as a design constraint rather than an aesthetic preference.