Speed vs. Quality: A False Dichotomy
Part #8: 10 Things I've Learned In 10 Years as a Software Engineer
This is part #8 of the series 10 Things I've Learned In 10 Years as a Software Engineer, you can find previous ones here:
“There’s no time for that! Our deadline is in a few days, we don’t have time to write good code”, I said to a more senior teammate suggesting I make a change to the code I was working on.
We had a big demo coming up, and my code was littered with hardcoded values, magic strings, terrible structure, and no tests. Worst of all, because of how I structured it, it took 20+ minutes to manually test even the smallest changes.
The quality of my code was slowing me down. But because of the urgency, I didn’t feel like I could spend any time improving it for fear of missing the deadline. It’s hard to know if pausing to improve the code quality would have helped enough to meet the deadline (I actually can’t remember what happened, I think we did hit the deadline but the demo got cancelled or something like that 😆). What I do know for sure is that the poor quality of my code was tangibly slowing me down, and if I had continued going down that road, speed only would have continued to plummet.
There’s this underlying belief in the industry that speed and quality are somehow at odds with each other. “Fast” implies shortcuts, hacks, and maybe some late nights. “Right” it implies slow, calculated, and precise. Seems reasonable, right? We’ve all heard things like this:
“If you want it done right, we need more time!”
“We didn’t have time to test it”
“Quality takes time, you can’t have it fast”
It’s not hard to arrive at this conclusion. Writing tests, thinking through good abstractions, these do take time—they’re not free. But just like in my story above, bypassing good engineering practices ultimately will slow you down, even in the short term. Quality begets speed, it’s not an either or.
Let’s illustrate with an example: F1 racing, the fastest cars and racers on the planet. Have you ever seen a pit crew change the tires during a race? They do it in a few seconds! Do you think these teams sacrifice quality in order to go fast? No, the amazing quality they have is precisely what allows them to go fast. The processes, the tools, the training—everything about it is engineered meticulously so they can go as fast as possible.
The trick is that building a metaphorical software “engine” does require consistent investment and effort, which of course takes time. But if you don’t build it, there’s no way you’re going to be able to go fast when it truly matters:
Production outages
Hard deadlines (e.g. a Black Friday sale or a demo at a big conference)
Pivoting priorities to compete in the market
So what does “good” look like? Is it meeting a certain threshold for unit test coverage? Is it writing perfectly modular and clean code? Those might be outputs of a good engine, but they’re not attributes of the engine itself. I think a good engine boils down to these three things:
You can deploy to production quickly
You can deploy to production confidently
Your architecture allows you to pivot (relatively) easily
#1 means you have good CI/CD, #2 means you have good testing, and #3 means you have good code, although the specific details will vary widely depending on the context.
For example, when you’re at an early stage startup, #1 and #2 you basically get for free. You can push to production easily because you probably only have a few customers and a simple deployment. You can push confidently because you have a solid mental model of the whole system in your head, and you can probably manually test the whole user flow in a few minutes. When you’re at a Big Tech company with billions of users, the first two get waaaaay harder and require much more investment to keep up with.
#3 is more ambiguous, but think of this way: if your organization needs to make a big pivot (e.g. migrating cloud platforms or onboarding a new customer), how much of your code needs to be rewritten? If you find yourself rewriting your entire codebase because you moved from Azure Functions to AWS Lambda, you’re doing something wrong. You’ll certainly need to make changes, but they should be isolated, not ripple through the entire codebase.
Another example: imagine your company decides to expand internationally, and suddenly all your hardcoded date formats, tax calculations, and currency conversions need to be updated. If these concepts were well-isolated, this is a manageable change. If they’re tangled throughout the codebase, it’s a nightmare.
This doesn’t mean blindly over-engineering everything in the name of quality. Just like an F1 team doesn’t replace every part of the car at a pit stop, you need to invest your time in the right places and with the right timing—it’s highly contextual.
Summary
If you want to sustain going fast, it’s crucial to have good quality. But good quality doesn’t mean just dogmatically following engineering best practices—it means consistently tuning your code, architecture, and processes to help you move fast, confidently, and adapt to anything that comes your way.
The next time you’re under pressure to hit a deadline, ask yourself: are you moving fast, or are you just scrambling? If your code slows you down today, it will only get worse tomorrow. Invest in your engine—not just to ship faster now, but to stay fast when it matters most.