Stop Over-Engineering with the "Rule of Three"

We have all been there: staring at a block of code and feeling the urge to abstract it into a generic, highly flexible utility function. We want our code to be "future-proof," so we add layers of abstraction, configuration objects, and complex inheritance hierarchies before we even have a second use case. This is where maintainability dies. Premature abstraction creates "indirection overhead," making it harder for the next developer (or future you) to trace the logic through a maze of unnecessary interfaces.

A practical rule to live by is the Rule of Three. When you write a piece of logic, write it concretely the first time. If you find yourself needing it again, copy-paste it the second time (yes, duplication is often cheaper than the wrong abstraction). Only when you are writing it for the third time should you perform a refactor to extract the shared logic.

By delaying abstraction until you have actual patterns to observe, you ensure that your code remains "just enough." Your abstractions will be based on real usage patterns rather than guesses about how the system might evolve. This keeps your codebase lean, readable, and significantly easier to debug when things inevitably change.