It's not a rhetorical question.

Who, and why, do people care if your app is slow? What is the purpose of the code you're writing? Whom does it impact? And where is the author going with this?

Today I came across a post on social media discussing the benefits of offloading heavy data operations to the database for improved performance. The logic is sound: databases are highly optimized for data storage and retrieval, and we've all witnessed how a piece of well-crafted SQL can work wonders in a fraction of the time their application code would take to run.

Fast is good. We all like fast!

So it follows that we should leverage the database wherever possible to squeeze out all of those performance gains, right? As with everything, of course, it depends.

The issue with this line of thinking is that it assumes there are no constraints on time or budget, and that making the tech run fabulously is our only concern.

Writing and maintaining SQL can be challenging — most people, including myself, find it more difficult than coding in their application
language. Crafting a highly performant SQL query could take ten times longer than jotting down a few lines in a typical programming language. Code is also read more often than it's written; by creating complex queries, you're burdening others — or future-you — who need to comprehend your brilliant solution. And what happens when requirements change and the query needs updating? The problem is multiplied.

While there are other factors to consider in choosing between SQL and application code, this performance conundrum services as a vehicle to illustrate a prevalent sense of tunnel vision we developers often suffer from: that we must spend our time optimizing our code.

Yet, writing software is not an isolated, purely academic activity. There's some value to be gained from what the software does, and limits on time and budget

Let's consider a scenario: you have a functioning method that retrieves entities from a database and updates them iteratively. It's not particularly fast, and SQL would offer a significant speed boost. So, should you rewrite it in SQL?

Zoom out. What's the actual impact here?

Does it run in the background, once per day, and complete in 10 minutes? Or does it execute for every request on every page, and add 2 seconds to customers' wait times?

Are there other priorities to address? Maybe we have a critical security hole that's being exploited right now and costing the business millions; or maybe our customers are internal and only load the application a couple of times per day.

We can't deliver quality software without knowing where to spend the quality budget. It's easy to get sucked into the weeds and forget about the bigger picture, and we'd all be better engineers if we kept reminding ourselves that the code in front of you — heck, the entire app — is just a small part of a larger machine.

That machine delivers real value to real people. Your optimization may not.

Before blindly "writing code" to improve an application, pause and reflect on why you're doing it — and who cares. There's always room for improvement, but remember, perfect is the enemy of good. Your time is finite, so spend it wisely.