Is Taking Small Steps Always a Good Idea?

The best way to develop software is by taking small steps. At least, that’s what all software methodologies tell us. But is it always the case? Maybe sometimes leaps are more efficient? Some argue that making small changes takes more time but it’s always safer. Is it that simple?

Some Facts About the Brain

The following two facts about the brain can help us to answer these questions:

• Our working memory is extremely small. Some early studies showed the average human cannot hold more than 7 objects in their working memory. But more recent studies showed that the number is actually 4.
• Loading objects (or memories) into working memory takes energy. Accessing recent memories is much cheaper and faster. For instance, can you recall what you had for breakfast a week ago? It’s extremely hard and may take a few minutes. Now, what did you eat this morning?

When Taking Small Steps is More Efficient

Imagine yourself making changes to a project you haven’t touched since last year. You can still have a pretty good understanding of the domain and structure of the project. Since you know it quite well and the test coverage is good, you feel that taking large steps will be more efficient. After all, it’s you who have built the project.

The problem here isn’t with learning new concepts or technologies, but with accessing old memories. Taking a leap involves a lot of context switching, which means loading the same groups of objects into your working memory over and over again. That’s an extremely energy-demanding process. You will feel worn out after a couple of hours. Making small changes doesn’t require many context switches. And even when it happens, everything you care about is right there, in the code.

When Taking Larger Steps is More Efficient

Imagine yourself working on some feature for a month. Since all the concepts are already learnt, and the memories are fresh, loading them into your working memory is super fast and cheap. In the previous example trying to recall what some class was supposed be doing could take a few minutes, whereas in this example it’d take a fraction of a second. And as a result, shifting your attention from one class to another isn’t that tiring. So you can make changes in multiple places without losing a clear picture of your program.

Rule of Thumb

ACCESSING OLD MEMORIES => SMALL STEPS

ACCESSING ONLY RECENT MEMORIES => LARGER STEPS

Summing Up

When uncertain, take small steps. Everyone emphasizes the safety of this approach, but it also can be less tiring, and, therefore, you can stay productive the whole day.

Knowing the code and being able to quickly load this information into your working memory can make context switching rather negligible. In this case, don’t be afraid to take larger steps. Most likely it’ll be faster.

Follow @victorsavkin to read more about programming and self-development.

If you liked this, click the💚 below so other people will see this here on Medium.