Why Performance Should Never Sacrifice Maintainability in Code

Programmers are often impatient, whether tormented by Windows' long boot time or the obvious benefits of faster code, and they show an unparalleled passion for performance.

C# was initially criticized for its automatic garbage collection and perceived poor performance.

DataSet was slammed when developers inserted millions of rows to expose its performance issues.

Linq received flak for using reflection and auto‑generated SQL, with many questioning the efficiency of hand‑written queries.

Even today, many developers stubbornly use stored procedures with thousands of lines and ask, "What is the purpose of the business layer?"

When leading a team, I often find performance discussions the hardest; ignoring performance makes code unreadable, while emphasizing it can lead to bizarre compromises. Ultimately, I tell developers that the only judgment criterion for code is maintainability, performance issues aside .

Destroying Readability

A recent code review revealed a developer using First() instead of Single() in LINQ, claiming it was faster. The conversation highlighted that First() stops after finding the first matching element, while Single() scans all results to ensure uniqueness, contradicting the developer's assumption about performance.

The developer insisted that First() was faster even with indexes, showing a misunderstanding of how indexes work and the importance of clear intent in code.

Readers still debating Single() vs First() should loudly chant three times: Readability! Readability!! Readability!!!

Assumptions

Common mistaken assumptions about performance include:

My understanding is completely wrong.

My understanding isn’t wrong, but the underlying system has already optimized the issue.

My understanding is correct and the system has not optimized it.

Even with caching, performance is not guaranteed; indiscriminate caching can degrade the entire system.

Optimizations often stem from “what we assume” rather than measured bottlenecks, leading to trade‑offs such as increased CPU load for reduced disk I/O, or higher memory pressure for faster algorithms.

Hard to Maintain

An anecdote from a personal project illustrates maintenance pain: storing previous/next blog IDs directly in the database seemed efficient, but handling deletions, category navigation, and user‑specific visibility quickly turned into a tangled double‑linked‑list nightmare.

Eventually, the code was reverted to simple database queries, raising the question of whether the original “performance” gain was worth the maintenance cost.

Reasonable Waste of Hardware

Many programmers wonder why they don’t use the most performant solution available. The answer often lies in perceived waste: saving a memory module by spending a week optimizing code may please a boss, but the real cost is the developer’s time, which is paid hourly.

Historically, hardware upgrades have outpaced software optimizations; buying better hardware is usually cheaper and more effective than micro‑optimizing code.

In conclusion, premature optimization is the root of many problems. Real performance improvements require identifying bottlenecks, and readable code is always easier to optimize.

Early optimization is the source of all evil.

Optimization must start with locating the performance bottleneck.

More readable code is always easier to optimize.

Hardware is always cheaper than software optimization.