An exploration of how velocity in software development creates a virtuous cycle of learning, decision-making, and execution that ultimately produces better outcomes, not just faster ones.
The assertion that "fast is better than slow" resonates with a fundamental truth about software development: velocity begets excellence. This principle, borrowed from soccer philosophy by the author, reveals a counterintuitive insight about programming talent. The most effective developers aren't necessarily those who produce the most perfect code, but those who move quickly through the development cycle, gathering feedback, learning, and improving at an accelerated pace.
The connection between speed and quality emerges from several mechanisms. When developers work quickly, they receive feedback sooner, enabling course correction before small issues become systemic problems. This rapid iteration creates a feedback loop that accelerates learning—developers try approaches, observe results, and incorporate lessons at a pace that simply isn't possible when working slowly. Over time, this compounds into significantly greater expertise and capability.
The practical strategies for increasing velocity outlined in the article address common productivity bottlenecks without resorting to unsustainable hustle culture. The advice to "don't delay" tackles the human tendency to postpone difficult beginnings—a behavior that often stems from discomfort with uncertainty. By addressing problems immediately, developers avoid the mental tax of carrying unresolved tasks, which can drain cognitive resources and reduce overall productivity.
Similarly, the concept of "reclaiming small chunks" challenges the myth that deep, uninterrupted work is the only path to productivity. In reality, most developers face constant fragmentation in their workday. Learning to effectively utilize these smaller time blocks—perhaps by addressing small bugs, responding to simple emails, or making quick improvements—can reclaim significant productive time that might otherwise be lost to context switching or passive consumption.
Perhaps most compelling is the 70% rule for sharing work. This principle directly confronts the perfectionism that often plagues developers. By sharing work when it's approximately 70% complete, developers invite earlier feedback, reduce the risk of building in the wrong direction, and create opportunities for collaborative improvement. The discomfort of sharing imperfect work is outweighed by the benefits of earlier feedback and the ability to course correct more efficiently.
The advice to "pick your battles" recognizes the finite nature of attention and energy. In collaborative environments, excessive focus on minor details—what the author calls "bikeshedding"—can significantly slow progress without meaningful improvement. By focusing on substantive issues and letting minor details be resolved by the original author, teams can maintain velocity while still benefiting from review.
The counterpoint to "fast is better than slow" might argue that haste makes waste, that careful deliberation prevents errors, or that technical debt accumulates when moving too quickly. These concerns have merit, but they represent a false dichotomy. The article doesn't advocate for recklessness or sacrificing quality for speed. Rather, it proposes that certain types of speed—particularly in feedback loops, learning, and iteration—actually improve outcomes.
The principle of "doing only what's required" offers a middle path between minimalism and gold-plating. By focusing on the essential requirements of a task, developers avoid the uncertainty of over-engineering and the potential mismatch between added features and actual needs. This approach respects the reality that software requirements are often imperfectly understood and likely to change, making extensive future-proofing a risky proposition.
The implications of this velocity mindset extend beyond individual productivity to team dynamics and organizational culture. Teams that collectively embrace "fast is better than slow" create an environment where experimentation is encouraged, feedback is valued, and learning happens continuously. This cultural shift can dramatically improve a team's ability to adapt to changing requirements and technologies.
For organizations, this suggests that hiring for velocity—identifying candidates who demonstrate quick learning, decisive action, and comfort with iterative development—may be more valuable than hiring for raw technical prowess alone. The evidence suggests that velocity itself cultivates technical excellence over time.
The article's closing refrain—"Don't question why. Fast is better than slow"—serves as both a mantra and a challenge. It asks developers to examine their own habits and assumptions about productivity, to identify self-imposed constraints that limit their velocity, and to experiment with new approaches to working faster without sacrificing quality. In a field where technology evolves at an accelerating pace, the ability to learn, adapt, and execute quickly may be the most valuable skill of all.
For those interested in exploring these ideas further, Jamie Brandon's posts on Speed matters and Moving faster offer additional perspectives on productivity in software development. Oliver Burkeman's writings on the 70% rule can provide further insight into embracing imperfection as a path to progress.
Comments
Please log in or register to join the discussion