One of our jobs as programmers is to think ahead so that we build the right things in the right order and at the right time.

“Ok, I’m gonna build this to do that, and then I’m going to add X so I can do the other thing that will do Y and everything should fit together.”

Our everyday thought process

The problem is sometimes we’re overthinking it. Sometimes we don’t need that extra class or that extra parameter. And that method we think we’ll use later might never be called at all.

Everything we write has a cost. Every extra class, variable, method, or parameter we add makes our code harder and harder to understand and support.

The reason why we fall into this trap is that we often don’t have enough information about what we’re building. We know the bulk of it, but details always seem to be slipping through the cracks. Building extra stuff is our way of trying to catch those hidden details. We call it speculative generality.

One way to avoid speculative generality is by taking a crossword approach.

The most effective way of solving a crossword puzzle is by filling in the easiest words first. Find and complete them, and you get more information about those other hard words you don’t really know what they are and how to solve.

The same principle can be applied when writing software. Instead of building a component from the inside out, do the opposite and start from the outside in.

Stop trying to figure out the hardest parts and go for the easy ones first. This way, while you move towards the core of your component, you’ll uncover more and more details about it.

Start by picking the smallest possible feature.