Imagine you’re building a house out of wooden blocks.
Wooden blocks are easy to build with but they make a somewhat fragile structure. As you’re putting a new block in place, you accidentally bump the house and the whole thing comes tumbling down. The various shapes of blocks get all mixed together when the house crashes. It takes you several minutes to get the house rebuilt to the point of progress you were at before.
Once you’re almost done rebuilding the house, you accidentally bump it again and you send it crashing down a second time. You have to spend another several minutes rebuilding it. This process repeats several times before you finally succeed in building the house to completion.
In certain ways, writing a computer program is like building a house out of blocks. If you make a big enough mistake, you can throw the whole area you’re working on into disorder. Often, the degree of disorder is so great that it’s cheaper just to revert to where you were at some point in the past and start over than it is to recover from where you are now.
Order and chaos
As I’ve observed programmers working over the years (including observing myself), I’ve noticed two possible states a programmer can be in: order and chaos.
In a state of order, you’re in control. You know what you’re doing. Every step you take is a step that gets you closer to your objective.
In a state of chaos, you’re flailing. You’re confused. Your program is broken and you don’t know how to fix it. Chaos is a very expensive state to be in.
The cost of chaos
It costs drastically more to enter a state of chaos and then get back to order than it does to just stay in a state of order the whole time.
I think of order and chaos like a thin trail through thick, dark woods. Order is the trail and chaos is the woods. If you allow yourself to stray off the trail, you might be screwed. It can be so hard to find the trail again that you might never find the trail again. Even though it costs a little extra effort to pay close attention to the trail as you follow it, the cost is a tiny one, and that cost is obviously much lower than the cost of losing the trail and dying in the woods.
What causes programmers to enter a state of chaos, and how can they avoid allowing that to happen?
What causes chaos
Entering a state of chaos while programming might seem like an unavoidable fact of life. And to a certain extent, it is. But some programmers spend almost all their time in a state of chaos while others spend almost all their time in a state of order. It’s not just luck. They’re doing something different.
As I see it, the main risk factor for chaos is length of feedback cycle. The longer the feedback cycle, the higher the chances that something is going to go wrong. And the bigger a change, the harder it is to determine what went wrong, because there’s a greater amount of stuff to dig through in order to find the source of the problem.
How to stay in a state of order
The way to minimize your chances of slipping into a state of chaos is to work in tiny changes and check your work after each change.
As I described in my post about programming in feedback loops, this type of working process can look something like this:
- Decide what you want to accomplish
- Devise a test you can perform to see if #1 is done (manual or automated)
- Perform the test from step 2
- Write a line of code
- Repeat test from step 2 until it passes
- Repeat from step 1 with a new goal
Working in feedback loops of tiny changes is like hiking a trail in the woods and looking down every few steps to make sure you’re still on the trail.
Takeaways
- When you’re programming, you’re always in either a state of order or a state of chaos.
- Recovering from a state of chaos is expensive. Never entering a state of chaos in the first place in cheap.
- The way to avoid entering a state of chaos is to work in feedback loops.