Why 100 lines of code is better than just 2?

In programming, there's a constant push for efficiency. We refactor, we optimize, and we often praise the developer who can solve a complex problem with the fewest lines of code. But what if I told you that a longer, more descriptive solution can be monumentally better than a super-short one?

Let's explore this with a classic problem: You have 9 balls, and one of them is heavier than the others. Your task is to find the heavier ball.

The Simple, Obvious, and Short Solution

When faced with this problem, the most direct approach is to check every single ball. You pick a standard weight (one of the balls you assume is normal) and compare every other ball to it until you find the one that's heavier.

In code, this brute-force approach looks incredibly simple and concise.

The "2-Line" Solution:

#include <iostream>
using namespace std;

int main() {
    int ball[] = {1, 1, 1, 2, 1, 1, 1, 1, 1}; // The 4th ball (index 3) is heavier
    int standard_weight = 1;

    for (int i = 0; i < 9; i++) {
        if (ball[i] > standard_weight) {
            cout << "Heavier ball found at index " << i << endl;
        }
    }
    return 0;
}

This code works perfectly. It’s easy to understand and gets the job done. In the worst-case scenario, it performs 9 comparisons. Simple, effective, and short. Why would you ever need more code than this? The simplicity is its greatest strength, but it is also its greatest weakness. It works for 9 balls, but it hides a significant performance cost when the problem scales up.

The Hidden Cost: An Introduction to Time Complexity

The "cost" of an algorithm isn't measured in dollars, but in how much time and memory it requires to run as the input size grows. This is known as Time Complexity, often expressed using Big O notation.

The simple loop is a perfect example of O(n) complexity, pronounced "Big O of N". Here, n is the number of balls. This means the time it takes to find the ball is directly proportional to the number of balls.

• 9 balls: up to 9 comparisons

• 100 balls: up to 100 comparisons

• 1,000,000 balls: up to 1,000,000 comparisons

The algorithm doesn't get any smarter; it just works harder as the input grows. This is why brute force is often not a scalable solution. Because we can be smarter.

The "100-Line" Logical Solution

Now, let's forget about iterating. Instead, let's think like a puzzle solver. What if we had a balance scale? We don't need to weigh each ball individually. We can weigh them in groups. This "divide and conquer" strategy is the foundation of many powerful algorithms.

This is where the "longer" code comes in. It doesn't just iterate; it executes a deliberate, multi-step algorithm that is far more efficient.

The Balance Scale Solution:

#include <iostream>
using namespace std;

int main() {
    int ball[] = {1, 1, 1, 2, 1, 1, 1, 1, 1}; // The 4th ball (index 3) is heavier

    // --- First Weighing ---
    // We divide the 9 balls into three groups: A, B, and C.
    int sum_A = ball[0] + ball[1] + ball[2];
    int sum_B = ball[3] + ball[4] + ball[5];

    // We place group A on the left side of the scale and group B on the right.
    if (sum_A == sum_B) {
        // If they balance, the heavier ball must be in the group we didn't weigh: group C.
        // --- Second Weighing (Group C) ---
        if (ball[6] > ball[7])
            cout << "Heavier ball is at index 6" << endl;
        else if (ball[7] > ball[6])
            cout << "Heavier ball is at index 7" << endl;
        else
            cout << "Heavier ball is at index 8" << endl;

    } else if (sum_A > sum_B) {
        // If group A is heavier, the ball is in group A.
        // --- Second Weighing (Group A) ---
        if (ball[0] > ball[1])
            cout << "Heavier ball is at index 0" << endl;
        else if (ball[1] > ball[0])
            cout << "Heavier ball is at index 1" << endl;
        else
            cout << "Heavier ball is at index 2" << endl;

    } else { // sum_B > sum_A
        // If group B is heavier, the ball is in group B.
        // --- Second Weighing (Group B) ---
        if (ball[3] > ball[4])
            cout << "Heavier ball is at index 3" << endl;
        else if (ball[4] > ball[3])
            cout << "Heavier ball is at index 4" << endl;
        else
            cout << "Heavier ball is at index 5" << endl;
    }

    return 0;
}

Refactoring for Reusability: Applying the DRY Principle

Take a close look at the code above. The logic for the "Second Weighing" is repeated three times. This violates a core programming concept: DRY (Don't Repeat Yourself). Repetitive code is harder to maintain and prone to bugs. If we find a mistake in that logic, we have to fix it in three separate places.

Let's refactor this by creating a helper function. This function will take the starting index of a 3-ball group and find the heavier ball within it.

The Refactored, "Smarter" Code:

#include <iostream>
using namespace std;

// Helper function to find the heavier ball within a group of 3
// It takes the array and the starting index of the group (0, 3, or 6)
int findHeavierInGroup(int balls[], int startIndex) {
    if (balls[startIndex] > balls[startIndex + 1]) {
        return startIndex;
    } else if (balls[startIndex + 1] > balls[startIndex]) {
        return startIndex + 1;
    } else {
        return startIndex + 2;
    }
}

int main() {
    int ball[] = {1, 1, 1, 2, 1, 1, 1, 1, 1};
    int heavierIndex;

    // First Weighing: Compare group A (0-2) and group B (3-5)
    int sum_A = ball[0] + ball[1] + ball[2];
    int sum_B = ball[3] + ball[4] + ball[5];

    if (sum_A == sum_B) {
        // Heavy ball is in group C (6-8)
        heavierIndex = findHeavierInGroup(ball, 6);
    } else if (sum_A > sum_B) {
        // Heavy ball is in group A (0-2)
        heavierIndex = findHeavierInGroup(ball, 0);
    } else { // sum_B > sum_A
        // Heavy ball is in group B (3-5)
        heavierIndex = findHeavierInGroup(ball, 3);
    }

    cout << "Heavier ball is at index " << heavierIndex << endl;
    return 0;
}

Now our main function is clean, readable, and clearly shows the high-level logic. The messy details of comparing individual balls are abstracted away into a reusable function. This is what writing maintainable code looks like.

So, Why is the Longer Code Better?

This is the heart of the matter. The "better" code isn't about having more lines; it's about having a better algorithm and structure.

1. Algorithmic Efficiency: O(n) vs. O(log n)
   The brute-force loop was O(n). The balance scale method is O(log₃ n), or "log base 3 of N". Because we divide the problem by 3 at each step, the number of weighings grows incredibly slowly.

   Let's revisit our comparison, this time with O(log n):

   • 9 balls: 2 weighings (log₃9 = 2)

   • 27 balls: 3 weighings (log₃27 = 3)

   • 729 balls: 6 weighings (log₃729 = 6)

   • 1,000,000 balls: Just ~13 weighings!

The difference is staggering. The O(n) approach would need a million comparisons, while our O(log n) algorithm needs only 13. This is the power of a superior algorithm.

2. It Represents a Smarter Thought Process
   The brute-force loop is mindless. The balance scale algorithm is intelligent. It shows a deeper understanding of the problem. It divides the problem into smaller pieces and eliminates possibilities, which is the core of efficient problem-solving and computer science.

3. Scalability and Future-Proofing
   The refactored code with the findHeavierInGroup function is built for growth. If we expanded this to solve for 27 balls, we would simply reuse the same function. The underlying logic is sound and scalable, whereas the brute-force method just becomes slower and more inefficient.

4. Code as a Model of the Solution
   The longer, refactored code clearly models the real-world solution. The main function represents the first weighing, and the findHeavierInGroup function represents the second, final weighing. This makes the code's intent much clearer to other developers.

Conclusion: Think in Algorithms, Not Just Lines of Code

The title of this article is a provocation. More lines of code are not inherently better. But code that embodies a more efficient, intelligent, and maintainable algorithm is always better than a shorter, brute-force alternative.

The "2-line" solution is easy to write. The "100-line" solution is easy to scale, faster to run, and demonstrates a much more sophisticated approach to problem-solving. It teaches us to think about efficiency (Big O), code structure (DRY principle), and clarity.

The next time you solve a problem, don't just ask, "How can I get the answer?" Ask, "What is the most intelligent way to find the answer?" Often, the code that reflects that intelligent process is the code that is truly better—no matter how many lines it takes.