This is part of a series on Unix Design Principles to help us design code that can be written faster.
In this post, we’ll discuss the Rule of Economy.
Rule of Economy
The rule of economy:
Programmer time is expensive; conserve it in preference to machine time.
It has two caveats. If your product is faster machine time, then you can trade your time for machine time.
If you’re broke, then more machine time isn’t an option.
Real World Application
In this section, I’ll walk you through how to apply this rule in the real world. I had a real life design choice and this principle influenced the decision.
In another life, I run engineering for a startup, Backtester.io. It’s an easy-to-use online financial backtester. The rule of economy helped me design the “analysis” feature. Here’s some quick background:
A financial backtester is a simulator. Users specify parameters, run an simulation (called a “backtest”), and get results. They can use it two ways:
Run a “backtest”. The user specifies every parameter manually and the simulator returns detailed results.
Run an “analysis”. The user specifies all but one parameter. The machine then varies the last parameter (stock hold duration) and runs a backtest for each value, returning a table of abbreviated results.
I fully built out running a backtest. Next up was designing and implementing analyses. The UI was straight forward, but it was less clear how the browser would call the backend. I thought of two ways to do it:
Implement a new backend API, “run-analysis” and have the browser call it. the API:
computed some data
reuses the condition values to run each simulation with varying “stock hold durations”. This reuse prevents needless waste of CPU cycles.
Returns only the displayed abbreviated data to minimize traffic between the client and server
Have the browser call the pre-made “run-backtest API” multiple times, one for each varied value for the “stock hold duration”. Take the detailed data response, throw out most of it, keep the abbreviated response, and display that.
Option 1 is quite performant and thrifty. It reuses values saving cyles. It minimizes the data sent over the network, keeping down the latency. It even keeps the whole interaction as a single http request-response which minimizes the http and tcp overhead.
Option 2 is also performant and thrifty. Not with respect to machine time. It’s terrible for all of the reasons option 1 is great. It recomputes often. It floods the wire with unnecessary data. It even uses multiple http requests and pays for the overhead. But with respect to developer time, it’s outstanding. It’s much faster to implement and maintain.
The rule of economy is clear here: option 2.
It’s your job
Sometimes customers want faster software. Great, spend your time to make it happen.
Sometimes you have time and no money. In the short term, you can’t buy more machine. However, in the long term
if buy compute
which frees your time
which you spend to ship more code
which gets you paid
which buys compute…
You create a positive feedback loop of more money, more compute, and more time.
Why people violate the rule of economy
The rule of economy sounds great, and there are caveats, so then why do people violate it? What’s the temptation?
Bean counters. AWS cloud bills and engineering equipment costs are easy to measure. A bean counter will go into a meeting, blast a metric showing how much “waste” there is in cloud computing. The company can be more profitable if this number goes down smaller (without considering loss of engineering productivity).
Engineers are human. Performance tuning is fun. Humans sometimes do fun things.
Engineers are human. Some engineering cultures value pointless performance tuning. Engineers want to fit in.
Fighting for the rule of economy
The rule of economy is a fight. Other forces don’t want you to follow it. Fight back.
Bean counters hate the rule of economy. They get paid when you don’t spend money. They don’t get paid when you code faster (you do).
Their primary weapon is the “machine cost” metric.
Your counter-weapon is the productivity metric.
The desire to have fun is good to engineers. We like coding, so we do it for fun, so we get better, and then we get so good, we get paid obscene amounts of money to do it. Keep having fun.
However, sometimes it’s fun to squeeze performance out of a machine even when it’s not a requirement.
The primary weapon of fun seeking is the emotional brain hijacking your intellect. It teases you with the rush that comes with squeezing performance.
Your counter-weapon is to stand up. Feelings pass. If you feel the urge, stand up and take a walk until the feeling passes. The time spent walking will be far less than the time wasted saving abundant cycles.
We saw in this piece “the rule of economy” and how it means that we should trade-off programmer time over machine time.
We saw the caveats. Sometimes it’s our job and sometimes we’re broke.
We saw how to use it to make a real design decision, to be thrifty with code, not cycles.
We even saw some temptations to violate the rule and how to fight them.
Next week, we’ll cover “The Rule of Separation” which teaches us exactly how to modularize code. If you don’t want to miss out, just click “Subscribe now”