Building for future speed
Building for future speed
Since I started at my new job, being basically the engineer in a super small but incredibly fast scaling team, one of my main concerns has been the classic:
How can we smash out the necessary features in a way that actually allows us to keep velocity over time?
Classic question..
Someone way smarter than me once taught me that our principles are only really important once we push things to the limit. Discipline, for example, is easy to prioritize when you have all the time in the world. When you have time, you can always fix things after this little commit.
A crunch is when you find out what your past few months of commits are actually worth.
So is there a secret to knowing what to pay interest on?
I posted a version of this question on LinkedIn the other day:
Around 20% of my commits last 30 days are refactors and I'm not sure if its because the entire problem domain here is new to me, I'm dealing with debt at a faster rate vs "pre-ai" age or if I'm just creating debt faster and dealing with it in the same rate as before?
So I went and looked. Last 30, 60, 90 days, same author:
| Window | refactor + test | fix |
|---|---|---|
| Last 90 days | 17% | 17% |
| Last 60 days | 20% | 15% |
| Last 30 days | 27% | 11% |
The refactor share went up, sure. But the answer to my own question is hiding in the right column, the fix percentage dropped. If I were just generating debt faster and clearing it at the same rate, fixes would be flat or rising.
Two budgets
The framing I keep coming back to. Every commit spends from two budgets:
- Today: What ships this week
- Tomorrow: How cheap the next change is
The trap is overdrawing tomorrow's budget to top up today's - the classic // TODO: clean this up after launch. It's a loan at usurious interest, and we almost never pay it back voluntarily.
The discipline isn't no shortcuts. It's noticing which budget you're spending from, and refusing the commits that quietly borrow from tomorrow.
The hardest call of the month
I really prefer black-box integration tests as my default, with focused unit tests sprinkled in where the complexity actually lives. That style only works if the integration tests are fast, and our Spanner emulator just wasn't.
So mid-month, it was time to pay up. Ripped it out and migrated every domain onto a Postgres testcontainer substrate. It cost me roughly two days to migrate over to a test setup that runs in around 5 seconds instead of minutes.
This looks like a pure spend on todays budget. Which is true, it's just that spending a bit of todays budget buys me TONS of freedom for tomorrow! It's not just speed of test runs.. It lets me continue writing tests that match our path, and it let's every feature land in a place where I don't have to rewrite even more!
So is there a secret?
Two things that turn out to be one thing.
Refactor commits aren't just code cleanup - they're receipts. They're what makes the cost of next time's shortcut legible to you.
The shortcut you take in this crunch is the one your future self pays for during the next one.
You don't refuse the shortcut on principle. You refuse it because you have your own commit log telling you what last time cost.
Out.