Iterative Full Implementation Enables Software Virtuality

This conversation, stemming from Brent Simmons' observation of achieving complete app control, delves into the profound challenge of software mastery and the elusive state of "virtuality." Dave argues that true control is only attainable after multiple iterations of a complex piece of software, a hard-won battle against inherent chaos. The hidden consequence revealed is that the path to such mastery necessitates embracing full implementation, even for experimental features, because partial solutions fail to provide genuine feedback. This insight is crucial for developers and product managers who must navigate the tension between rapid innovation and foundational stability. Those who understand this will gain a significant advantage by investing in the iterative development process, even when it demands immediate discomfort for long-term payoff, ultimately building software that recedes into the background, allowing users to focus entirely on their own work.

The Mirage of Immediate Control

The quest for complete control over software, a state where source code feels harmoniously ordered rather than chaotically complex, is a rare achievement. Brent Simmons' recent reflection on reaching this pinnacle for the first time in his career serves as a powerful catalyst for Dave's analysis. Dave, however, tempers this optimism with a pragmatic observation: this state of grace is typically the result of the fourth or fifth full implementation of a given piece of software. The implication here is that true mastery isn't about finding a shortcut, but about enduring the iterative cycle of building, learning, and rebuilding. The more complex the software, the more intertwined its components, and the greater the challenge in maintaining that elusive order.

This iterative necessity creates a fundamental tension: how do you experiment with new ideas without destabilizing a mature codebase? Dave’s answer is stark: you can't. Trying out a new feature requires building it out fully. There's no halfway measure that yields genuine insight. He uses the analogy of a car: you can't understand how a car drives with a placeholder for the steering wheel or brakes. Similarly, software intended for human operation demands a complete implementation to be truly understood and evaluated. This means committing to building the entire feature, even with the knowledge that it might be discarded later. The immediate cost is significant--building something that may never see the light of day--but the downstream effect is a deeper, more accurate understanding of the feature's feel and function.

"You can't go halfway there in order to find that out, because it needs everything pretty much. You know, it's kind of like you can't find out how a car is to drive if you do it with a sort of placeholder for, I don't know, something important, the steering wheel, the brakes, the gas pedal, which I don't know if you're going to leave out."

This commitment to full implementation, even for experiments, is where delayed payoffs begin to manifest. Teams that embrace this principle are building a more robust understanding of their software's operational dynamics. They are not just solving an immediate problem; they are gathering data on how the entire system behaves under new conditions. This patience, this willingness to build out and then potentially discard, creates a competitive advantage. Competitors who opt for partial implementations or avoid complex features altogether will never gain this depth of understanding. They might appear faster in the short term, but they are building on a foundation of incomplete knowledge, which will inevitably lead to unforeseen complications down the line.

The Unseen Complexity of Operation

Dave admits he's not currently in that ideal state of complete control with his own projects. The exception, Frontier, was by design built for user extensibility, which inherently fostered a different kind of internal coherence. This highlights that while the ideal state of software mastery is hard to achieve, intentional design choices can pave the way. However, the general challenge remains: balancing the need to try new ideas with the imperative to maintain internal order. The conventional wisdom might suggest focusing solely on new feature development, but Dave’s analysis points to the critical flaw in this approach: it neglects the operational reality.

The act of building software is, at its core, about creating something for a human to operate. This means not just building the feature, but ensuring it integrates seamlessly and functions reliably. Dave emphasizes that even seemingly simple software often requires human intervention to diagnose and fix issues. The temptation is to cut corners on the internal architecture or refactoring when experimenting with new features, to save time. But this creates technical debt that compounds. The immediate benefit of faster feature delivery is overshadowed by the long-term cost of a more brittle, harder-to-maintain system.

This is where the concept of "virtuality," as described by Ted Nelson, becomes relevant. Dave recounts a demo of his early outliner software to Nelson, who declared, "That's virtuality." Dave unpacks this as the "suspension of disbelief." When software achieves this state, the user forgets they are interacting with a tool. Their focus is entirely on their task, their ideas flowing unimpeded through the interface.

"You forget you're using the software. What you're doing is the thing that you're doing. And if it really is good, it's totally out of your way. And your fingers know how, at the base of your spine, your fingers know how to make your ideas appear on the computer screen without you having to think about that at all."

This state of effortless interaction is the ultimate payoff of mastering software complexity. It’s not just about having clean code; it’s about creating an experience so seamless that the tool disappears. The skiing analogy further illustrates this: the initial runs are fraught with mechanical considerations and fear. But with practice, the skier transcends the mechanics and simply is the act of skiing. The same applies to software. When the tool is out of the way, the user is fully present in their own work. This is a profound competitive advantage--building software that doesn't just function, but enables.

The contrast with bike riding is telling. While exhilarating, skiing involves significant overhead--travel, equipment, lifts. Bike riding, by contrast, offers a more immediate and accessible path to that feeling of effortless flow. Dave suggests that AI tools might, in the future, make achieving this state of software mastery more broadly accessible, potentially lowering the barrier to entry for that "suspension of disbelief." However, the fundamental principle remains: true mastery requires a deep, iterative engagement with the software's complexity, not a superficial approach.

Charting the Course to Virtuality

• Embrace Iterative Full Implementation: Commit to building experimental features completely, even if they might be discarded. This provides the necessary data for genuine evaluation and prevents the compounding of technical debt from partial solutions. Immediate discomfort (building potentially throwaway code) for lasting advantage (deep understanding, cleaner architecture).
• Prioritize Operational Coherence: Recognize that software is for human operation. Invest in internal architecture and maintainability alongside feature development. This is not a secondary concern but a prerequisite for long-term success. This pays off in 6-12 months as system stability increases.
• Develop for Seamless Interaction: Aim for the "suspension of disbelief" where the software becomes invisible. Focus on user experience that allows for effortless flow of ideas and actions. This is a continuous investment, with noticeable payoffs over 12-18 months.
• Invest in Foundational Understanding: Accept that complex software requires multiple iterations to achieve mastery. Resist the temptation to rush through early implementations. This is a long-term investment, with payoffs realized over years.
• Leverage AI for Deeper Insight, Not Shortcuts: Explore AI tools to aid in understanding complexity and generating robust implementations, but do not rely on them to bypass the essential work of iterative development and operational excellence. Immediate action: Explore AI tools this quarter. Long-term payoff: Potential for broader mastery in 2-3 years.
• Document and Learn from Each Iteration: Actively capture learnings from each implementation cycle, especially regarding what worked, what didn't, and why. This builds a knowledge base that accelerates future iterations. Immediate action: Implement a post-mortem process for major feature builds.
• Seek the "Bike Riding" Efficiency: While full-scale implementations are necessary, look for opportunities to achieve similar insights with less overhead, much like bike riding is a more efficient path to flow than skiing. This might involve internal tools or focused prototyping. This pays off in 3-6 months by streamlining the learning process.