More Code Does Not Equal More Progress — Why Reducing Code Is the Ultimate Productivity Hack

In software development, it’s tempting to think progress is measured in lines of code. It wasn’t all that long ago that developers’ progress and productivity was tracked by the number of lines of code they delivered. After all, more code means more features, more services, more sophistication, bigger numbers to sell to your executive team — it feels like progress.

But as any seasoned architect will tell you, more code simply means more risk, more testing, more bugs, more maintenance, and more opportunity for things to break, usually on Sunday night (or am I the only one lucky enough to experience that).

The real productivity hack? Writing less code.

Look at it this way: every line of code is a long-term liability. It needs to be tested, deployed, monitored, patched, and maybe eventually rewritten or, better yet, eliminated. Doubling the size of the codebase doesn’t double the value — it doubles the surface area for bugs. Larger codebase makes it harder to see potential security issues. It is also more likely to generate technical debt (we will discuss the technical debt in future articles, for now just accept this fact).

Here’s one concrete example. I saw a team build a custom authentication system when AWS Cognito already existed. It worked fine for its intended application — until one day someone noticed that some users didn’t have to authenticate to gain access to protected resources. It took weeks to trace the issue to a particular piece of code that allowed trusted IPs access to the system. Fixing the issue easy, but it used up developer resources looking for security holes instead of focusing on delivering customer value. Using an existing managed service would cut almost a thousand lines of code and saved weeks of engineering time.

The best systems I’ve worked with aren’t the ones using the most microservices, or the largest GitHub files. They’re the ones where the design is streamlined, the code is lean, and are built on strong foundations of existing libraries — not duplicated effort.

If I could create the whole application using pre-built libraries for all the business functionality, only using few hundred lines of code to tie it all together, I would do it. But since that is not possible, we must strive to optimize our solutions to be as lean and streamlined as possible.

And the next time someone is tempted to equate app quality with “more code,” remember: the best solution is often the one that removes code, not adds it.

What do you think? Have you seen situations where deleting code created more business value than writing it? I’d love to hear your stories.