Why Writing 100 Lines of Code Can Be Better Than Just 2

👋 Introduction

Many times, people think writing less code is better.

But in programming, less code doesn’t always mean faster code.
Sometimes, writing a few extra lines makes your code run faster, especially when input becomes large.

Let’s understand this with a very simple and real-life type example — the 9 balls problem.

🎯 Example - 9 Balls Puzzle

Problem Statement :

You have 9 balls.
Out of them, 8 balls are equal in weight, and 1 ball is heavier.
You can use a balance scale only 2 times, and you have to find out which ball is heavy.

Solution :

Way 1 – Simple code, but slow when input grows❌

Let’s say we check each ball one by one using a loop:

Just 2–3 lines. Looks clean and short.
But this method will compare all balls, one after the other.
So for n balls, it takes up to n-1 comparisons.

This is called O(n) time complexity — more balls = more time.

But Just Look 2nd Method of Solving Problem

Way 2 – Write more code, but solve faster✅

Let’s divide the 9 balls into 3 groups:

• Group A → ball 1, 1, 1

• Group B → ball 1, 1, 2

• Group C → ball 1, 1, 1

• add them and its addition is resp.A = 3, B = 4, C = 3

• Now we compare Group A and Group B on the balance:

In just 2 comparisons, we find the heavy ball.
Even if the input becomes 27 balls, with the same logic, we can solve it in 3 steps only.

This method takes more lines of code — but the logic is smart.
It doesn't check each ball. It skips many checks by dividing.

This is called O(1) time — fixed steps, no matter the size.

🏁 Conclusion

• More lines of code is not a bad thing.

• Focus on the logic and performance, not just on short code.

• Time complexity helps you write efficient programs.

• Remember: short code may look cool, but smart code runs better. 😊

📌 Note :

Sometimes, fewer lines are better too — if the logic is clear, correct, and efficient.

It's all about choosing the right approach for the right problem.