Your Time is Expensive, Your Machine’s Time is Not

Revisiting the rule of economy

I was poking around for quotes to include for a talk, when I decided to revisit the UNIX philosophy of designing computer systems. I like to revisit this every once in awhile to remind myself of the time-honored, elegant rules in making and keeping things simple.

The rules are great and well worth reading (whether you’re a developer or not), but The Rule of Economy really stood out to me:

Programmer time is expensive; conserve it in preference to machine time.

I ended up sending this rule to my team at Pivotal, and it prompted a lively/great conversation. You see, lately we’ve been talking about how Pivotal Cloud Foundry enables humans to work on the problems they care about, instead of redoing the same task over and over again.

Processing power has increased by 10X (at least) in the last 20 years, but our brains just don’t evolve that fast. Here are some of the top ways a programmer’s time (our processing power) is wasted:

1. Spending too much time sorting out requirements. It takes a lot of time to just to get to a point where everyone understands what will work for a project, especially across large organizations. For example, security and networking teams will have vastly different perspectives on what’s “required” before a project goes live.
2. Redoing the exact same task again and again. This often comes down to button pressing. For instance, Netflix makes it so we don’t have to press the “next episode” button, it’ll just start automatically.
3. Waiting a long time for feedback. Say it takes an hour to compile your application, that means every small change will add an hour of wait.

Here’s my view on how we can avoid the biggest offenses in time consumption, using the rule of economy.

Implement as soon as possible

• Spending lots of cycles on requirements in planning an application carries multiple offenses in time-wasting. It takes developers away from doing what she/he does best: creating software. It’s better to implement quickly, learn from the machine, and adapt your plan. When it comes to software, all the planning in the world is no replacement for actually putting your ideas into action, and seeing what that yields.

Automate as much as possible

• While sometimes unavoidable, being asked to do the same exact task day after day can be annoying. Once a problem has been solved, it’s important to pick out the parts that are common and automate them.

Speed up the feedback loop

• It’s really hard to be iterative if your feedback loops are slow. There’s a dream that all programmers share, where our intentions flow into a computer and it acts on them in real-time. For me, getting feedback reported and understood as fast as possible without human intervention leads to more interest and higher job satisfaction.

The unstated complication, however, with the rule of economy, is being a good judge on whether a programmer’s time is being used wisely. Sometimes this will be in how you choose your tools, as this all informs the process and saves you time.

We work with machines everyday. I would argue they are here to do the necessary but lower-value tasks that we need to get done everyday, at great speeds — and to tell us how they’re doing.

This is what frees up our slower (and more expensive) brains to focus on higher value problems.

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.