Avatar
i make the terraform which is like when you terraform mars but for computers and i write go lang which is google language for going fast and i maintain modules which are like modular furniture but for the cloud which is where data lives in the sky and i do machine learning pipelines which is when the machine learns about pipes and i build ML platforms which stands for machine learning but also could be maximum likelihood or maybe municipal library anyway its scalable which means it can scale like a fish but in the cloud which is AWS or AZURE or google cloud which is where the googles live i live in the CLI which is command line interface but also could be clitoris but no its the terminal which is like the airport but for commands and i created red teaming which is when you team up with red people to hack the mainframe and im a mitre contributor which is the hat that bishops wear but for security and OWASP which is when you get wasped by a OWL and debian which is like saying damn but with a B i write blogs which are like logs but for the web and if you enjoy my code which is community code because its for the community please reach out and connect which is what we do on linkedin which is the professional facebook but with more people lying about their skills anyway thanks for reading this is my bio and i hope you like it and please hire me or give me money or stars on github which are like real stars but smaller and on a website

Rushing Toward Rewrite

Published on 26 Mar 2025

This is part three of my microblog series exploring the subtle dysfunctions that plague engineering organizations. After discussing over-abstraction as a liability and unpacking how excessive toil kills engineering teams, this post tackles a nuanced threat: when “moving fast” becomes a cultural shortcut for cutting corners.

Move Fast and Don’t Break Everything

A former CEO of mine used to say: “Be fast or be perfect. And since no one’s perfect, you better be fast.” Sounds cool until that motto becomes a shield to skip due diligence, code reviews, and even basic security hygiene. Speed wasn’t a value—it was an excuse. PRs rushed. On-call flaring. Postmortems piling. And still, engineers asking for admin access “to move fast.”

Spoiler: they didn’t need it.

The deeper problem? We weren’t a scrappy startup anymore—we were operating at enterprise scale with a startup mindset. The cost of speed was technical debt, fragility, and a long tail of rework. When I transitioned to a new role (back in startup mode) I heard the same “move fast” mantra. But this time, it hit differently. Because here’s the truth: moving fast is possible without setting your future self on fire.

Here’s what I’ve learned:

1. Fail fast—but fail forward. Don’t just throw things at prod and hope they stick. Structure your failures. If a solution’s not viable, surface that early with data and a path forward. Good failure leaves breadcrumbs for the next iteration.

2. Build for iteration. Forget perfect. Aim for clear next steps. Your v1 should be designed with a roadmap in mind. Where will this evolve? What trade-offs are you making? Ship it—but know how you’ll ship it better.

3. Stay modular. Design with exits. If your observability pipeline starts with a pricey SaaS, fine. But make it swappable. Keep your vendor coupling thin so you can self-host later without a complete rewrite.

4. Be honest about scale. What worked for a team of 10 won’t work at 100. “Move fast” looks different when customers depend on your uptime. Match your velocity with the blast radius of your decisions.

We glamorize speed, but the smartest teams know when to slow down, breathe, and make thoughtful decisions that stand the test of time. Move fast—but don’t break the foundation.

related posts