In our Ruby on Rails app, we have a set of conditions to define the status of a user. Currently, there is logic that checks if those conditions are true given a user. We are in the process of writing code that will fetch a set of users from the database based on these conditions.

A couple of my colleagues believe that we should reuse the logic for checks and loop over the entire set of queried records as opposed to writing a complex query to fetch the set. Their reason is that the definition of conditions would remain in one place and would help avoid maintenance overhead in case the definitions change.

On the other hand, I think the processes are inverses of each other and the maintenance overhead is desirable over the inefficient code approach.

  • 1
    How many users are there in your DB? Hundreds? Do whatever is easiest. Millions? Querying every user won't scale. But instead of rewriting the logic as a query, it may be possible to query for a set of feasible users, then only run the logic for that smaller set.
    – amon
    Jul 10, 2019 at 8:45
  • 1
    None. From the company' standpoint, both are counterproductive and expensive. While the cost of the inefficiency is relatively easier to estimate, the cost of maintaining complex code is not. In S.E most of the resources spent on software go to the maintenance. If the software is not cheap to maintain it's feated to die sooner than later.
    – Laiv
    Jul 10, 2019 at 9:07
  • @Laiv, I understand that both are evil, but the question was more about which one is the lesser of two evils. Jul 10, 2019 at 9:10
  • 2
    And you asked to wrong audience. You should ask this to the stakeholders. To the people that look at this from a different point of view. A non-technical one, because the implications are not technical, they are economical and strategical. When business is at risk of losing capabilities or at risk of becoming gradually less beneficial then technicians should raise the hand and let decide people who actually understand the application as meaning to an end, not otherwise like we developers often do.
    – Laiv
    Jul 10, 2019 at 9:13
  • Could you just change “more disputable” to “less undesirable” since none of the alternatives is in any way desirable.
    – gnasher729
    Jul 10, 2019 at 18:19

3 Answers 3


Good code,

  1. Works,
  2. Is easy to read, test and maintain.

In that order. The only reason to favour efficient code over easy to maintain code is if that inefficient code doesn't work.

So go with that easy to maintain code, unless it's too inefficient and prevents the code functioning properly, and that "functioning correctly" includes being fast enough to be responsive to the user.

If doesn't function correctly through being too slow, then profile the code to find the bottlenecks and address them. Do not assume a particular piece of code is the problem, confirm it first through profiling.

  • 1
    One of the important requirements for oft-used library-code is generally high efficiency (in addition to correctness and robustness, which are assumed), so there is less of a dichotomy in that case. Jul 10, 2019 at 8:55
  • @Deduplicator, as ever, for every rule, there's an exception :) Your point is well made.
    – David Arno
    Jul 10, 2019 at 9:02
  • “Works” includes “works fast enough to not get complaints form users about slowness”.
    – gnasher729
    Jul 10, 2019 at 9:51
  • @gnasher729, "and that "functioning correctly" includes being fast enough to be responsive to the user". I agree and said so.
    – David Arno
    Jul 10, 2019 at 9:52

If you are using an SQL database, you can be sure that this database is really fast at running a query that filters out say 100 out of a million users. Thousands of developer man years have been invested to make that kind of query fast. In that case, doing a million queries will not be just inefficient, it will be inefficient on a massive scale.

Do yourselves a favour and create a large database with test data, then compare the performance, then make an educated decision.

  • 1
    This was my concern too: Choosing maintainability in the short term over efficiently querying what might become a massive table in the future. As far as I am concerned, it is more or less technical debt that we will have to pay in the future. Jul 10, 2019 at 10:16

Implement using the maintainable inefficient code and add log statements that measure

  • how much time is actually spent in that specific part.
  • how often per second is this code executed.

If you later find out that you have 10 million users and that the inefficient code is called 10 times per second start thinking about optimisation.

Optimizing code without analysing that the optimisation is really needed is often called Premature_optimisation

I assume that the semantics of "status of a user" will change over time. The later you start optimizing this the less time you spend fixing two implementations.

  • 1
    Your last sentence is demonstrably false. If I fail to choose sensible data structures for their appropriate performance characteristics from the start, for example, or choosing any technology or technique that clearly will not meet my performance requirements. Jul 10, 2019 at 15:29
  • I agree that a bad database structure can make implementing the more efficient code much harder. The question remains is the efficient is really necessary
    – k3b
    Jul 10, 2019 at 15:57
  • 2
    I didn't say anything about a bad database structure. Good performance is a feature, not an afterthought. Jul 10, 2019 at 16:00
  • Well there is optimal performance and good performance and bad performance. In this particular instance, I would opt for confining the checks in one location and see if the performance good enough. Going for optimal performance is a complete waste of time, but do include comments on how to possibly improve performance in the future. Jul 14, 2019 at 19:27
  • 1
    PS: the last statement is not demonstrably false given the context of this thread Jul 14, 2019 at 19:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.