Performance vs. Maintainability: Why Maintainability Should Take Precedence

Architecture, just these two words carry weight. The goal of architecture is maintainability, while performance is also important.

======================

Let's begin.

======================

Programmers seem impatient, perhaps tormented by Windows' long boot times, or because performance improvements are obvious… In short, I find that most programmers have unparalleled focus and passion for performance!

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

When DataSet first appeared, many developers inserted millions of rows to demonstrate its performance issues.

Linq is also blamed for using reflection and auto‑generated SQL, questioning whether hand‑written queries are faster.

…

Thus even today I still see many programmers unrepentantly using stored procedures that can run thousands of lines, and they innocently ask, “What is the purpose of the business layer? What can it actually do?”

When leading a team, I fear discussing performance the most. If you ignore performance, the code can become unbearable; if you emphasize performance, you never know what trouble it will cause. It’s about mastering the “degree,” which is hard to articulate. After many setbacks I had to say, “Your code has only one evaluation criterion: maintainability. Performance issues can be ignored for now!” This answer doesn’t satisfy especially ambitious programmers.

So I will first talk about performance, hoping to help everyone understand the issue more clearly.

1. Performance is not unimportant, but it is less important than maintainability. To understand this, first grasp the importance of maintainability (see my previous post about weeks spent finding bugs); then realize that solving performance problems can often be done with many non‑code methods, whereas maintainability relies on code; finally remember: No sacrifice, no victory!

2. Therefore, in most cases when performance and maintainability conflict, maintainability wins. We use other ways to compensate for insufficient code performance.

Empty preaching is meaningless. Let’s illustrate with examples!

Destroying Readability

Recently, while reviewing code, I noticed a programmer using LINQ’s First instead of Single. I asked why, and he replied, “First is faster!” The conversation went as follows:

“How do you know First is faster?” I asked.

“ First returns the first matching value and stops searching; Single scans all results then picks one.”

“Are you sure? Do you know about indexes?”

“…?”

I explained that indexes are tree structures that speed up queries.

He still insisted on First, claiming it’s always faster.

Finally I asked, “Why did Microsoft create Single then? To mislead you?” He fell silent.

When I first entered the field, I collected articles like “Top Ten Rules for High‑Performance Programming,” which advised always using StringBuilder instead of ‘+’, etc. Many praised those articles, but over time I grew skeptical, thanks to mentors like “老赵” on CSDN. I later realized such advice is superficial; only through real dialogues can I truly understand the trade‑offs.

All these sacrifices of performance through simple wrappers serve one important purpose: improving readability. If you sacrifice readability for performance, you lose the ability to maintain the code.

Continuing the example, the programmer’s initial performance assumptions are often naïve. There are three typical situations:

Their understanding is completely wrong.

Their understanding is not wrong, but the underlying system has already been optimized.

Their understanding is correct and the underlying system has not been optimized.

The first two are easy to grasp; the third fails because it doesn’t align with the hardware environment.

The simplest example is caching. In interviews, when asked “Can caching improve performance?” the trap answer is “Not necessarily.” Everyone assumes caching speeds up performance because CPU and disk are slower than memory, yet uncontrolled caching can also cripple a system.

Many similar examples exist. You might save a disk read, but increase CPU load; you might optimize an algorithm, reducing CPU cycles but raising memory pressure. No free lunch exists. The same code can behave differently as data grows or hardware changes.

Therefore, many “optimizations” are just assumptions. Instead, test performance first, then target the real bottlenecks. This returns us to the earlier question: is code readability more important? Only readable code lets you quickly locate the bottleneck; unreadable code makes optimization impossible.

Hard to Maintain

Another humorous example is my own project “创业家园”. I wanted a blog to show the previous and next post links. The naive approach is to query the database twice, but I thought, “Why not store the previous and next IDs in the blog record?” I believed a single query would fetch everything. It sounded brilliant.

The nightmare began.

First, when publishing a blog, we need to set its previous post. The next post doesn’t exist yet, so we also set the previous post’s “next” field. Later we added “previous in category” and “next in category” fields, ending up with four fields: Previous, PreviousInCategory, Next, NextInCategory. It felt awkward but acceptable.

When a post is deleted, we must remove it from a doubly‑linked list—painful. Adding statuses like “blocked” further complicates matters because visibility now depends on the current user. Updating the previous/next links for each status change became a nightmare.

Eventually, after tears, I reverted all the complex logic back to simple database queries. Did this cause performance issues? If so, could a cache solve it?

Reasonable Waste of Heap Hardware

After all this, I wonder if anyone truly reflects on why we avoid higher‑performance methods.

Because it feels like waste!

What? Are you kidding? My code saved at least one memory stick! That’s only because you’re still thinking like a “poor student”. You spent a week optimizing code (ignoring the added maintenance cost) to save a memory stick for the boss. Do you think the boss will pat you on the back? The boss won’t care.

When you were a student, your time cost was zero; now you earn a salary every day.

Improving performance through code is a compromise for insufficient hardware (think of 1980s game programmers who lacked enough memory for color graphics). In most cases, buying better hardware is cheaper and more effective than code optimization. Hardware costs keep dropping according to Moore’s law, while programmers’ salaries do not necessarily follow.

Why do we still use Windows 10, which consumes more resources than Windows 95? Why do we install a 10 GB Visual Studio 2013? Why do we all use C# instead of assembly? We enjoy the results of accumulated civilization, but sometimes we cling to “performance” for the wrong reasons.

One possible reason programmers obsess over performance and ignore maintainability:

Performance is easy to understand—slow vs. fast; maintainability is vague and only becomes apparent after years of operation.

If performance suffers, programmers feel ashamed; if requirements change, they curse “who’s asking for changes again?”

Does this sound familiar?

Finally, some maxims to consider:

Premature optimization is the root of all evil.

Optimization must first locate the performance bottleneck; otherwise anyone can point at code and demand optimization.

More readable code is always easier to optimize.

Hardware is always cheaper than software.

This article is reproduced from: 自由飞博客