When I began writing software nearly thirty years ago, my productivity was astonishing even by my own standards. As a student I often ended up building not only my own graduation projects but those of many others on the course. A small system that resembled a lightweight SaaS product, perhaps something for managing a logistics centre, took me ten to twenty hours of focused work from concept to delivery. I would imagine the structure, visualise the modules and then sit down and type until the system existed.
Today, with decades of professional experience behind me, I would not dream of delivering the same scale of functionality in such a short timeframe. My judgement is sharper, my technical depth far greater, and yet my raw development velocity has undeniably slowed. This contrast forced me to ask a question I avoided for years. If skill increases, why does speed so often decrease?
The answer has little to do with age. It has everything to do with clarity.
Clarity is the state in which the entire solution exists in your mind before your fingers touch the keyboard. The modules, the interfaces, the interaction patterns and the overall structure all form a coherent design long before implementation begins. When clarity is present, coding feels almost procedural. You are not discovering the system; you are transcribing it.
Without clarity, development becomes a walk through uncertainty. Each step reveals another small segment of the problem. You take a decision, advance a little further, reconsider, adjust, and repeat. It works, and it often feels intellectually engaging, but it is painfully slow. You carry unresolved questions, juggle half-formed ideas and constantly reconstruct the mental model of the system as you go. A colleague of mine once described this state as having porridge in your head, and the metaphor has stayed with me ever since.
This distinction between clarity and exploratory development explains far more about practical productivity than any methodology debate. It exposes the structural weaknesses of both upfront architecture and highly iterative design processes.
Upfront architecture, dominant in the early 2000s, assumed that structure must be defined before coding begins. Teams created documents, UML diagrams and design artefacts intended to guide the implementation. Beyond being detached from the realities uncovered during development, this approach suffers from its own weight. It relies on knowledge transfer. Someone designs the system, someone else implements it, and the distance between these two minds must be bridged with documents. These artefacts take time to write, time to read and even more time to reinterpret when the real system inevitably evolves away from what was originally drawn. This heaviness slows work considerably.
Agile and Extreme Programming challenged this by allowing architecture to emerge gradually. Test-Driven Development was particularly influential in shifting design decisions into the coding phase itself. Yet the problem here is not slow architectural growth. The real friction appears when teams break work into units that are too small. XP explicitly warns against tiny user stories, sometimes referred to as sand stories. The comparison is precise. A grain of sand is trivial, but a pile of sand is nearly impossible to handle cleanly.
Sand stories are hard to estimate because their apparent simplicity hides their cumulative cost. Each story must be found in the backlog, reread to recall its intent, implemented, committed, tested, merged and then mentally closed before the next begins. None of these steps disappear simply because the story is small. When repeated dozens of times a week, they create a relentless pattern of context switching that shatters productivity. Instead of maintaining a stable mental model of the system, the developer must reconstruct it repeatedly. What could have been a continuous line of thought becomes a chain of micro-resets.
This is precisely why flow is so rarely achieved under such conditions. Flow is not mere concentration. It is the state in which the work becomes a single uninterrupted movement. Time disappears. The transitions between tasks feel natural, and functionality grows as part of one coherent narrative. Developers often describe their best work in this state, but they experience it far less often than they would like.
Flow depends entirely on clarity. When the architecture already exists in the mind, there is no need to pause and reorient. The developer moves seamlessly from one part of the system to the next, guided by an internal structure already understood. Without clarity, flow becomes practically impossible. With clarity, productivity can increase by an order of magnitude.
This leads to the practical question. If upfront architecture is too heavy and test-driven incremental design too fragmented, what should a developer actually do?
I believe the answer lies in something simple but rarely formalised: a personal architecture brainstorming session. This is not a traditional design phase and not a document intended for a team. It is a private working session with a single purpose: to create clarity for yourself. The goal is to identify the functional territory large enough to support uninterrupted flow and to eliminate the repeated stops where you must rethink or redesign the structure mid-implementation.
In practice this session may involve sketching the main structures of the system, defining the interfaces you intend to use, outlining database tables or drafting empty modules that express the architecture’s shape. You are not designing every detail. You are building a mental framework that will hold together once you begin typing. When the framework exists, the coding phase is not the traditional design–code–test cycle. It becomes a process of filling in a structure that already has form in your mind.
A powerful side effect emerges here. Personal architecture does not require knowledge transfer. There are no diagrams to explain to others, no documents to keep in sync, no translation of one person’s thinking into another’s. You are aligning your own understanding with the work ahead, and that alone eliminates a significant portion of architectural overhead.
There is another intriguing implication. This approach aligns naturally with AI-assisted development. Generative tools perform best when expanding a clear skeleton. The personal architecture session becomes exactly that skeleton. You define the conceptual boundaries and relationships, and the AI accelerates the mechanical parts of implementation. Rather than replacing deep thinking, AI amplifies the value of a structure created through clarity.
In many ways, this combination mirrors the productivity we remember from our early years: rapid progress driven by a clear internal vision. The difference is that today the systems are larger, more sophisticated and far more demanding. Clarity, supported by personal architectural reasoning and strengthened by AI, may be the only path that restores that level of effectiveness without sacrificing quality.
About the author
Oleksii Smirnov is the Director of Software Planet Group and a software architect and developer with more than three decades of hands-on experience in building real products that people rely on every day. Based in London, he has spent his career at the intersection of engineering depth and practical business outcomes, helping companies turn complex domains into clear, usable systems.
Over the last 30+ years, Oleksii has designed and delivered software across several demanding industries: accounting, retail, edtech, and medical services. Each of these fields comes with its own vocabulary, regulations, and hidden edge cases, and his work has consistently focused on making that complexity manageable. Whether the task is creating robust accounting platforms, scalable retail solutions, learning products that genuinely support teachers and students, or medical systems.
He is also known as an early pioneer of the agile movement, adopting and advocating iterative development, close feedback loops, and engineering practices that keep teams fast without letting quality drift. At Software Planet Group, Oleksii combines leadership with active technical engagement. He brings the perspective of a long-time practitioner who has seen waves of tools and methodologies come and go, keeping what works and discarding what doesn’t. Living and working in London, he continues to build products, mentor engineers, and refine his craft, with a clear belief that good software is not about fashionable ideas, but about clear thinking, solid structure, and responsibility for the result.
