The Velocity Horizon: Rethinking Speed in Software Development

Throughout most of my career, I’ve observed a recurring tension within software teams.

On one side, there are those who want to build software the “correct” way, which is often perceived as slow. On the other, there are those who want features delivered quickly, even if that means cutting corners.

But I think this framing misses something important.

I believe most of us actually want the same thing: to deliver software quickly.

Personally, I get a real buzz from shipping features. I love knowing that something I’ve built is out in the wild, being used by real people, delivering value to users and ultimately to the organisation I work for.

I don’t want to spend months sitting on a feature, endlessly refining it. I want to see it released.

So perhaps the disagreement isn’t about whether we should prioritise velocity. It’s about how we achieve it.

And more importantly, over what timeframe are we trying to optimise it?

Option 1 — Cutting Corners

The first approach is to prioritise immediate delivery.

We make compromises to get features out as quickly as possible. We might accept technical debt, skip certain engineering practices, or settle for a less polished user experience.

In the short term, this can work remarkably well. Features get shipped, deadlines are met, and progress is visible.

But those shortcuts can carry a cost.

As technical debt accumulates, subsequent changes become more difficult. Bugs become more frequent, development slows, and eventually we may find ourselves rewriting functionality that was only recently delivered.

Effect on velocity: High initial velocity, potentially followed by a gradual decline or a sudden, expensive period of rework.

Option 2 — Doing It the “Correct” Way

At the other extreme, we prioritise engineering quality.

We invest in architecture, maintainability, automated testing, and robust solutions. The intention is to create a foundation that allows us to keep delivering software efficiently over time.

There is real value in this approach. A well-designed system can make future development considerably easier.

But it has its own risks.

We can spend weeks or months building abstractions and infrastructure for problems that haven’t materialised. We might design for requirements that never arrive, or create solutions whose complexity outweighs their benefits.

And sometimes the business simply needs a feature delivered within a timeframe that doesn’t allow for an extensive engineering effort.

Effect on velocity: Potentially slower initial delivery, with the expectation of greater velocity in the future. But that future benefit isn’t guaranteed.

Option 3 — Understanding the Velocity Horizon

The first two approaches are often presented as a choice between fast development with poor quality and slow development with good quality.

But I think this is the wrong way to look at the problem.

We aren’t simply choosing between fast and slow. We’re choosing when we want the benefits of our technical decisions to materialise, and how long we want those benefits to last.

This is what I think of as the Velocity Horizon.

Rather than asking which approach is fastest to implement, we should consider how each approach will affect our ability to deliver software over the coming weeks, months, and years.

Imagine we’re discussing four possible solutions to the same problem.

Approach	This sprint	Next month	Next 6 months	Next year
Quick and dirty	Fast	Rework required	—	—
Major architecture change	Slow	Slow	Faster	Faster
Pragmatic solution A	Medium	Medium	Medium	Medium
Pragmatic solution B	Medium	Medium	Rework required	—

These are illustrative scenarios, not predictions.

The interesting thing about this comparison is that there isn’t necessarily a universally correct solution.

If the feature is an experiment that may be discarded next month, the quick-and-dirty implementation could be an entirely reasonable decision.

If we’re building something central to the business that we expect to evolve over several years, investing in the architecture may be worthwhile.

And quite often, the best approach is somewhere in the middle.

Of course, predicting future velocity is difficult. We don’t know exactly how requirements will evolve, which problems we’ll encounter, or when a particular technical decision might become expensive.

But uncertainty shouldn’t stop us from having the conversation.

When discussing a solution, we should be asking:

• Will this approach still serve us in one month? Six months? Two years?
• How likely are we to revisit or extend this functionality?
• What is the cost of changing our approach later?
• What are the actual business deadlines, and what happens if we miss them?
• Are we making a deliberate compromise, or simply choosing what looks easiest today?

We don’t need precise answers. Even rough expectations can help us make better decisions.

The important part is making these trade-offs visible and aligning the team around them.

Conclusion

Optimising for velocity within the current sprint isn’t necessarily the same as optimising for velocity over the lifetime of a product.

Sometimes cutting corners is the right decision. Sometimes investing heavily in engineering quality is justified. And sometimes a relatively simple, pragmatic solution will outperform both.

The goal shouldn’t be to write perfect software, nor should it be to ship at any cost.

The goal is to deliver value quickly while preserving our ability to continue delivering value at the pace the business needs.

To do that, we need to look beyond the current sprint and start thinking about our velocity horizon.