Being fast matters
Exploring why speed in software engineering is a competitive advantage and how to achieve it without compromising quality
This is another brief post due to travel and time constraints.
Software Engineering is complex and demands significant energy from everyone in an organization. While some companies and teams can release features efficiently, others struggle with lengthy development cycles. There's also a third category: teams that ship quickly but with declining quality, causing customers to become wary of updates.
So, what's the best approach in software engineering—slow and deliberate or fast and ruthless? What many overlook is that you can be both fast and deliberate. It simply requires more energy and courage to achieve this balance.
Why fast matters
Speed in software engineering brings several critical advantages. Here's why being fast matters:
Fixing defects more rapidly
Delivering features to customers
Experimenting with proof of concepts and research
Outpacing competition
Being faster to market gives us a significant competitive advantage. Customers tend to view companies that can move quickly as having stronger engineering capabilities. In contrast, slower-moving companies are often seen as bureaucratic organizations that need months to implement even simple features.
Speed isn't just a nice-to-have—it provides real business value.
Is fast always better?
Some industries argue that moving fast is risky—particularly in regulated sectors like aerospace, space exploration, and railway systems. While no one disputes the need for careful development in these industries, being fast isn't counterintuitive. You can still outpace your competition with comprehensive in-house simulation systems and rigorous automated testing. In these sectors, you don't need to match the speed of Meta, Uber, or other rapid-delivery companies—you only need to be faster than your direct competitors.
The aviation industry illustrates this well. Since the barrier to entry is high, startups rarely disrupt this space. However, if you can maintain high quality while moving faster than your competitors, you'll succeed in the long run—and that's what truly matters.
Quality and being fast
People often doubt that you can create quality software quickly, and they have a point. However, time investment belongs in the planning phase, not during execution. Once you're writing code, it's too late if you haven't planned for quality and delivery.
We often get caught up in grand architectural designs and future scenarios—load handling, hybrid-cloud solutions, and fancy reusable web components. While these sound impressive, they're not the main priority. What truly matters is whether your architecture is easy to deploy and test. When these aspects are optimized, you can enhance quality through effective testing.
Most engineers, myself included, weren't trained with this mindset. I started early, attending technical school at 14, where we learned C, C++, Assembler, and more. My education continued with Java, Python, Perl, and even exotic web frameworks like Struts. We studied functional programming, object-oriented programming, and design patterns but never learned Test-Driven Development (TDD) or how to approach testing in large projects. Despite TDD being known since 2003, a year before I started university, we focused on XML, HTML, CSS, and other technologies instead of testing and deployment.
Our training had led us to believe that code quality alone ensured overall quality. This isn't true. Without deployability and testability, your code becomes a liability requiring significant resources to maintain.
But what is fast?
Being fast doesn't mean hacking code together without thinking. In my definition, being fast means creating a good product efficiently. A good product has three key elements:
Quality code
Comprehensive tests
Easy deployment and configuration
The key is to optimize primarily for testability and deployability. When you do this, you naturally design software that's easy to work with. This makes onboarding simpler and helps the system scale better. While this is easier said than done, modern tools have made it much more achievable than in previous years.
Fast through AI
I know some will see the AI batsignal flashing again, but the changes since ChatGPT's release have been remarkable. The initial large language models and ideas pale in comparison to what's possible today—and it's only been a few years since ChatGPT's launch on November 30, 2022.
This year, we've witnessed a significant advancement with agentic coding AIs. What makes them different?
The first coding AIs were essentially sophisticated autocomplete tools (which remain valuable)
Next came chatbots, which were useful but—requiring users to break down their work and carefully structure their approach
Agentic coding changes this paradigm. While you still need to understand your goals, the process becomes more intuitive and effective at each step. Let me share an example I'm currently using.
Claude Code
Claude Code was released on February 24, 2025. It features a straightforward command-line installation process that creates a simple prompt interface.
Once you understand how to use it, it's incredibly powerful. The tool offers different levels of granularity depending on your needs—whether you're exploring or working on production code. For quick projects where you care more about results than the underlying code, it allows rapid development without getting bogged down in implementation details.
This is perfect for one-off scripts or proof of concepts. For example, in my previous blog post, I simply:
Fed Claude Code a CSV file containing Knights Capital's historical data
Showed it an example image of my desired output
Within 2–3 minutes, it generated the stock chart you can see in that post. Previously, even with my programming experience, this would have taken about an hour—especially when considering the time spent fine-tuning design elements for a one-time visualization.
For more specific, long-lasting results, you can define a Claude.MD file that specifies rules. Let's apply this to our focus on being fast: you can instruct Claude to adhere to TDD principles and prioritize easy deployment. Simply include these requirements in your prompt, along with any preferred coding standards, and it will generate a markdown file for your review.
By incorporating tests, you also guide the agent in maintaining code integrity. This makes future changes easier and—you guessed it—faster.
Through the MCP standard, you can extend the agent's capabilities to include web browsing and searches. This third-party connectivity could eventually expand to include access to your Jira and Confluence data.
Does this eliminate the need for engineers? Not at all. Without human guidance, the AI lacks context for problem-solving and understanding real-world constraints.
Security, quality, and other critical variables depend on your expertise to make informed decisions and provide appropriate AI input. While the technology simplifies tasks for those who understand it, its accessibility has led to problematic outcomes. Inexperienced users are creating web applications vulnerable to hacking and security breaches. Though such issues aren't new to software development, they're likely to become increasingly prevalent.
What is the conclusion?
Being fast matters—not across the whole industry, but against your competition. Speed is always a choice; you can combine speed with quality, though it requires extra effort.
While AI makes this effort easier, you still need to understand the principles to create code that remains:
Fast to modify
Easy to deploy
High in quality a year from now
To conclude with a quote from the article from Brian Guthrie:
Some people argue that you shouldn’t optimize for speed, and focus a lot on getting each individual feature right instead. I disagree. Every feature is a bet on a some future payoff. Some pay off, some don’t, but all else being equal, shipping more frequently means more turns at-bat. More swings means more hits.
Moving slowly is often a choice: everyone involved has decided that speed is a subordinate requirement to talking to all the right people, writing all the right documents, and ticking all the right boxes. Sometimes that’s necessary. But the hardest part of moving fast isn’t execution; it’s deciding that it’s necessary, and then convincing people that it’s possible.