The Same Law Governs Good Code and Fast Queries: Make Work Easy to Skip

Jun 27, 2026

9 min read

1 views

86%

The hidden question behind elegant software

What if the real job of software design is not to make every operation clever, but to make as many operations as possible unnecessary?

That sounds almost backwards. We usually praise code for being reusable, expressive, and well factored. We praise databases for being indexed, optimized, and fast. But beneath both worlds is the same deeper principle: good systems do less work by making the right work easy to find. A class that does one thing well and a query that can use an index are solving the same problem in different costumes.

The tension is this: humans are tempted to optimize for flexibility at the point of creation, while systems reward specificity at the point of use. In object design, that means resisting bloated classes that try to do everything. In SQL, that means resisting expressions that force the database to inspect every row. The most maintainable code and the fastest queries are often the ones that leave the system with fewer choices, not more.

The best abstraction is not the one that can do anything. It is the one that makes the right thing obvious and the wrong thing expensive.

That idea connects clean architecture with query execution more deeply than it first appears. Both are stories about eliminating avoidable work.

Why flexibility often becomes a tax

Software developers love flexibility because it feels like future proofing. A class with many responsibilities can seem convenient because everything is in one place. A query with lots of functions, negations, and transformations can feel expressive because it says exactly what you want in one line. But both forms of convenience often hide a tax that is paid later.

In object-oriented design, the tax shows up as fragile code. When one class handles too many concerns, a small change in one behavior can unexpectedly break another. If a payment class also formats receipts, sends emails, logs metrics, and validates coupons, then every modification becomes risky because the class has become a crowded intersection. The system may look compact, but it is actually tangled.

In SQL, the tax shows up as full scans, unnecessary sorting, and expensive calculations. If a WHERE clause applies a function to an indexed column, the database often cannot use the index efficiently. If a leading wildcard is used, the engine may have to inspect far more rows than necessary. The query still works, but it pays in latency, CPU, and memory.

The pattern is the same: convenience at the surface can create hidden work underneath. The developer says, “This is simpler.” The machine says, “Now I have to check everything.”

That is why the most useful performance principle is not “be faster.” It is be searchable. In design, that means making responsibilities easy to isolate. In SQL, it means making conditions easy for the optimizer to exploit. The machine is always asking, “Can I narrow this down early, or do I need to explore the whole space?”

SOLID and SARGability are cousins

At first glance, object design principles and query optimization rules live in different universes. One concerns classes and dependencies. The other concerns predicates and execution plans. Yet they are surprisingly similar because both are methods for preserving the system’s ability to make efficient decisions.

Consider the idea of Single Responsibility. A class should have one reason to change. That does not merely make the class neat, it makes it legible. When a piece of code has a clear responsibility, the system can reason about it locally. You do not need to inspect unrelated behavior to understand a modification.

Now consider a SARGable query, one that allows the database to use an index effectively. The database can answer the question locally, by jumping to relevant entries instead of scanning everything. The query is not just faster because it is “optimized.” It is faster because it is narrowly readable by the execution engine.

This is the deeper parallel: both principles improve the system’s ability to bound the search space.

A well designed class bounds the search space of change.
A SARGable predicate bounds the search space of row lookup.
A clean dependency structure bounds the blast radius of a modification.
A usable index bounds the amount of data the engine must inspect.

In both cases, the problem is not raw computation. The problem is finding the answer without wandering through irrelevant territory.

Take a concrete example. Suppose you have a user table with millions of rows and an index on created_at. If you filter with WHERE created_at >= '2025-01-01', the database can likely use the index to jump to that date and continue forward. But if you wrap the column in a function, such as WHERE DATE(created_at) = '2025-01-01', you may force the engine to evaluate the function row by row before it can decide whether the row matches. The database did not become slow because the math is hard. It became slow because the path to the answer became opaque.

The same thing happens in code when a class exposes behavior through side effects and tangled internals. The method still works, but the dependency path becomes opaque. You can no longer tell what changes will ripple through the system.

Design is not only about what the system can do. It is about how directly the system can arrive at what it needs.

The real enemy is unnecessary interpretation

If there is one idea that unifies these domains, it is this: bad design makes the system interpret too much.

A bloated class forces future readers to interpret multiple responsibilities at once. A query with arithmetic on indexed columns forces the database to interpret each row before deciding what it means. A leading wildcard in a search condition forces the engine to interpret nearly every candidate string. Unnecessary sorting and grouping force the database to organize data before it knows whether that organization is even needed.

Interpretation is expensive because it delays certainty. The earlier a system can know what to ignore, the more efficient it becomes.

This is why filtering early matters so much in SQL. A WHERE clause is not just a syntax feature. It is an act of reduction. It tells the engine, “Do not reason about the whole table if only a small subset matters.” Likewise, in software architecture, a focused interface tells collaborators, “Do not reason about the whole object graph if only this capability matters.”

A helpful mental model is to think of every design choice as either reducing or expanding the surface area of interpretation.

Reducing interpretation

Use clear responsibilities in classes.
Keep dependencies narrow and explicit.
Write predicates that can leverage indexes.
Filter before sorting or grouping when possible.
Limit result sets to what the caller actually needs.
Avoid wrapping indexed columns in functions if the raw column will do.

Expanding interpretation

Put unrelated behavior in one class.
Hide dependencies behind generic utility objects.
Apply calculations to columns in the WHERE clause.
Search with patterns that begin with wildcards when prefix search would suffice.
Sort or group massive result sets before filtering.
Ask for more data than the application can realistically use.

The point is not that every function or transformation is bad. The point is that every extra layer of interpretation weakens the system’s ability to shortcut. And shortcuts are the difference between elegant software and merely correct software.

A better model: design for shortcuts

Most advice about clean code and performance can feel moralistic. Be modular. Be efficient. Avoid this. Prefer that. A more useful framing is simpler: design for shortcuts.

A shortcut is not a hack. It is a path that preserves correctness while reducing work. An index is a shortcut. A single responsibility is a shortcut. Early filtering is a shortcut. A clean interface is a shortcut. The best systems do not avoid work by being lazy. They avoid work by making the answer discoverable.

This suggests a useful test for any piece of code or query:

What is the smallest unit of truth here?
Can I express it without forcing the system to inspect irrelevant things?
Am I making future change easier, or am I just hiding complexity in a convenient place?

Imagine a reporting feature. A team wants a list of active customers who made a purchase last month. A naive implementation might fetch all customers, join all purchases, calculate a date difference for every row, sort the result, and then filter in application code. It works, and at small scale it may even feel fine. But each step adds interpretation. The database has to examine too much, the application has to compensate, and the business logic becomes harder to reason about.

A better version pushes the reduction closer to the data. Use the indexed date column directly. Filter active customers early. Sort only the rows that survive the filter. Retrieve only the columns the report actually needs. Now the system is not doing less because it is weaker. It is doing less because it is smarter about what can be ignored.

That same instinct governs good object design. If a service only needs validation, do not hand it a giant object that also sends emails and writes audit logs. If a payment workflow only needs to calculate a charge, separate that from notification, persistence, and formatting. The system moves faster when each unit has a shorter path to its answer.

This is why maintainability and performance are not separate virtues. They are often the same virtue seen from different time horizons. Maintainability makes future change cheap. Performance makes present execution cheap. Both are about reducing unnecessary effort in the right place.

Key Takeaways

Ask whether your design helps the system skip work. A good class or query makes the relevant path obvious and the irrelevant path ignorable.
Prefer specificity over cleverness. Narrow responsibilities and direct predicates usually outperform abstract, all purpose structures.
Filter early, both in data and in design. In SQL, reduce rows before sorting or grouping. In code, reduce responsibilities before they spread across modules.
Avoid forcing interpretation. Functions on indexed columns, leading wildcards, and overloaded classes all make the system inspect more than necessary.
Think in terms of search space. Great design shrinks the amount of territory the machine or reader must explore to find the answer.

The deepest lesson: elegance is the art of making work optional

The strongest connection between clean object design and SQL optimization is not that both are “best practices.” It is that both reveal a deeper law of computational elegance: a good system creates a narrow path from question to answer.

This reframes what we usually mean by good software. We often think of good software as code that is neat to read or fast to run. But the more profound standard is this: good software makes irrelevant work hard to justify. It refuses to pay for ambiguity. It treats every extra row inspected and every extra responsibility absorbed as a cost that must earn its keep.

That is why a clean class and a SARGable query feel so satisfying. They do not merely look organized. They respect the machine’s need for clarity. They say, in effect, “Here is the thing that matters. Nothing else should have to pretend otherwise.”

If you internalize that principle, you start seeing the same pattern everywhere. In APIs, in services, in SQL, in state management, in event handling. The question is no longer, “How do I make this more powerful?” The better question is, “How do I make the answer easier to find?”

And once you start asking that, you may notice something remarkable: the best software is not the software that does the most. It is the software that knows exactly what not to do.