Less is more - Code length in software

Introduction

One of the most valuable lessons in software engineering is that success rarely comes from writing the most code. It comes from solving problems with the least amount of complexity necessary.

The illusion

Many engineers initially associate more code with better engineering.

A large implementation can feel more complete. Multiple design patterns, abstraction layers, generic frameworks, helper classes and configuration options can make a solution appear sophisticated and future proof.

The illusion is that complexity signals quality.

In reality, users do not benifit form complexity. They benifit from the software that works correctly and can continue working as requirements evolve.

The number of files, classes, or lines of code says very little about the quality of a software. In many cases, the most elegant solution is the one that removes code rather than adds it.

Where does the illusion comes from?

Part of the illusion comes from how engineers are rewarded.

Writing code is visible. Removing code is not.

A developer who introduces ten new classes may appear productive, while another who simplifies those ten classes into three may appear to have done less work despite creating a better outcome.

Another source is education and early career experience. Many examples, tutorials, and conference talks focus on advanced patterns and architectures. Enginners are exposed to sophisticated solutions long before they encounter the maintenance cost of associated with them.

As a result, many developers learn how to add complexity before they learn when complexity is actually justified.

The Subconcious Urge to Write Fancy Code

Most developers enjoy solving problems, and complex solutions often feel intellectually rewarding.

There is a natural temptation to:

• Create generic frameworks
• Add extensibility points
• Introduce abstration layers
• Optimize for hypothetical future requirements
• Demonstrate knowledge of advanced design patterns

The problem is that software is read far more often than it is written.

A clever solution may impress its author today, but confuse ten other developers tomorrow.

Many mature engineers eventually discover that the hardest skill is not writing complex code. It is resisting the urge to do so when a simpler solution exists.

The best engineers are often not the ones who can create the most sophisticated design, but the ones who know when sophistication is necessary.

DRY (Don't Repeat Yourself)

The DRY principle teaches that duplication should be eliminated where practical.

Wen the same logic exists in multiple locations:

• Bugs must be fixed multiple times
• Changes become more expensive
• Behavior can become inconsistent By centralising common logic, developers reduce the amount of code they need to maintain.

HOWEVER, DRY is often misunderstood.

Many engineers aggressively abstract code after seeing only a small amount of duplication. They end up creating a generic solution that are harder to understand than the duplicated code they replaced.

True DRY is not about eliminating every repeated line. It is about eliminating duplicated knowledge while keeping the system understandable.

A little duplication is often less harmful than a bad abstraction.

YAGNI (You Aren't Gonna Need It)

YAGNI is one of the strongest arguments for keeping code small.

It states that developers should not implement functionality until it is actually required.

Engineers frequently build for imagined future requirements:

• Future integrations
• Future scalability
• Future flexibility
• Future customization

Most of these requirements never arrive.

The result is a code that consumes development time, increases complexity, and requires maintenance despite never delivering business value.

YAGNI encourages engineers to solve today's problem well and postpone tomorrow's problem until it becomes real.

Software should evolve in response to actual requirements, not speculation.

Minimal code, Minimal liability

Every line of code creates a maintenance obligation.

It must be:

• Read
• Reviewed
• Tested
• Documented
• Secured
• Debugged
• Refactored
• Upgraded

The amount of maintenance work tends to increase with the amount of code and complexity that exists within a system.

A feature that requires 500 lines of code is not just 500 lines today. It is 500 lines that the team may need to understand years from now.

When two solutions deliver the same business value, the smaller solution ususally wins because it has fewer failure points and lower long term cost.

The best code is not code that is clever, flexible, or architecturally impressive.

The best code is code that continues solving the problem while demanding the least amount of ownership from the people responsible for maintaining it.

Conclusion

The goal of software engineering is not to maximize code written. It is to maximize value delivered.

Complexity often disguises itself as sophistication, but complexity always comes with a cost. Principles such as DRY and YAGNI exist because they help engineers avoid unnecessary code and focus on what truly matters.

In the long run, teams rarely regret building something simpler. They frequently building something more complicated than necessary.

The less code you own, the less complexity you carry. The less complexity you carry, the easier it becomes to build, maintain, and evolve great software.