Pickup sticks is an old children’s game where you try to remove individual plastic sticks from a pile without disturbing the others. You start the game by holding a bundle of sticks in your hand and letting them go. Most of the sticks fall in a pile in the middle, while a select few roll away from the center.

The object is to remove as many sticks as you can from the pile, one at a time, without disturbing the other sticks. You lose your turn if any other sticks in the pile are disturbed.

Maintaining complex software sometimes feels a lot like this game. Each stick represents a feature or function. Sometimes a feature can live outside and completely away from the others. Other times it affects a few components. And still other times it’s completely intertwined with many other features.

Implementing a new feature is like adding a few new sticks into the mix. At a certain point, trying to remove any stick without disturbing the rest is nearly impossible. Complexity adds up fast.

As developers, we try our best to circumvent this by following good habits: encapsulating our code, scoping variables at the right level, breaking apart larger pieces of logic into bite-size chunks, or introducing patterns. It’s our valiant attempt to align all of our sticks in parallel, side by side, so they don’t touch each other. But consistently refactoring code into the “right” places while continuing to add more sticks into the mix can get hairy. It’s easy to let our guard down.

Every time we add a new feature, we stand the chance of disrupting a host of other features that might not, at first, seem directly connected. As we add more features, those disruption points grow pretty rapidly.