The Unseen Architecture: Why Software Survives (and Thrives)

This conversation with Nico Krijnen reveals a critical, often overlooked truth: the longevity and success of software are not solely dictated by elegant code or cutting-edge architecture, but by the human element and the continuous, messy process of learning. The non-obvious implication is that the most valuable asset in software development isn't the code itself, but the tacit knowledge embedded within the team, which, when lost, transforms robust systems into unmanageable legacy burdens. Engineers and technical leaders who grasp this will gain a significant advantage by prioritizing knowledge retention and feedback loops, moving beyond the "feature factory" mindset to build truly resilient and adaptable systems. This is essential reading for anyone building or maintaining software that needs to last.

The Unseen Architecture: Why Software Survives (and Thrives)

The pursuit of software that endures is a constant, often frustrating, endeavor. We're bombarded with the pressure to ship, to iterate, to constantly deliver new features. But what if the real work, the work that separates thriving software from the dreaded legacy code, begins after deployment? Nico Krijnen, with three decades of experience navigating the complexities of software development, argues that our conventional understanding of success -- a clean codebase, a well-defined architecture -- is incomplete. The true differentiator, he suggests, lies in the continuous learning and adaptation driven by the human element, a perspective that challenges the industry's often production-centric view.

The Starting Line is Production, Not the Finish

The prevailing narrative in software development often frames deployment as the finish line. Once the code is live, the task is seemingly complete, and the team moves on to the next feature. Krijnen, however, posits a radical shift in perspective: production is merely the starting line. This is where the real learning begins, where assumptions are tested against reality, and where the software’s true behavior is revealed. The feedback loops generated by live systems -- user interactions, performance metrics, unexpected failures -- are not hindrances but essential data points for evolution. Ignoring this post-deployment phase, focusing solely on shipping, means missing the critical opportunities to refine and improve.

"We're under a lot of pressure to ship new stuff constantly. That's the finish line, but I like to not think of it as a finish line. That's actually the starting line. That's where it gets interesting because that's where you start learning."

This perspective highlights a systemic flaw: the prioritization of new development over the understanding and refinement of existing systems. The consequence of this is a slow decay, where systems that are technically sound but not continuously learned from gradually become less valuable and harder to maintain. The immediate benefit of rapid deployment is overshadowed by the long-term cost of unaddressed learning and adaptation.

The Tacit Knowledge Imperative: Why Documentation Isn't Enough

A significant portion of Krijnen's analysis centers on the concept of tacit knowledge, a term popularized by Peter Naur in his 1985 essay "Programming as Theory Building." Tacit knowledge is the "know-how" that resides in people's minds -- the intuitive understanding, the accumulated experience, the feel for how a system really works, beyond what can be explicitly written down in code or documentation. This is the knowledge that allows seasoned engineers to diagnose complex issues in minutes, while support teams, armed with only the artifacts, struggle.

"The code and the documentation, the artifacts, the output of this software process was apparently not sufficient to be able to maintain, evolve, and fix stuff, etcetera. And then on the other hand, the people that had the ready knowledge, because they worked on it, they had the ready knowledge in their brain, the experience... This is tacit knowledge."

The danger lies in the loss of this tacit knowledge. When team members leave, whether through retirement or job hopping, the system's implicit understanding walks out the door with them. This knowledge loss is a direct pathway to legacy status. A system becomes legacy not just because its technology is outdated, but because the institutional memory of how it functions, how it breaks, and how to fix it, has evaporated. This creates a significant downstream effect: the system becomes a risk, unchangeable and unmaintainable, regardless of its initial design. The immediate advantage of a highly skilled, long-tenured team is the deep well of tacit knowledge they possess, a competitive moat that is difficult for newcomers to replicate.

The Illusion of Predictability: Embracing Evolvability

The desire to build for the future is natural, but Krijnen, echoing Barry O'Reilly’s work, cautions against over-engineering for hypothetical future needs. The future is inherently unpredictable, and attempts to architect for every possible scenario often result in unnecessary complexity. This added complexity, far from making the system more adaptable, can actually hinder evolution.

"My learning, like the stuff I build nowadays is always the minimal, just what I need now, and I make really sure that I I make it in such a way that it's easy to change so that when that future comes, I can just change it."

The more effective approach, Krijnen advocates, is to build minimally for the present need while prioritizing evolvability. This means designing systems and writing code that are easy to change. The assumption should be that what you build is wrong in some way, and the focus should be on optimizing the feedback loop to identify those errors quickly and iterate. This requires a conscious effort to make hard-to-change aspects, like database schemas or architectural decisions, as flexible as possible through tooling and deliberate design choices. The delayed payoff here is immense: a system that can adapt to genuine future needs rather than one burdened by speculative complexity. Conventional wisdom often suggests making architectural decisions early and sticking to them, but Krijnen’s approach suggests that making those decisions easy to change is the more durable strategy.

The Human Element in Systemic Design

Beyond the technical architecture, Krijnen emphasizes the socio-technical nature of successful systems. This means recognizing that software exists within a human context -- the team that builds it, the users who interact with it, and the organizational structures that support it. The composition of the team is paramount. A blend of specialized and broad skill sets, coupled with diverse disciplines (designers, UX specialists, even growth hackers when needed), fosters innovation. Critically, Krijnen highlights the value of juniors bringing fresh perspectives that can challenge the ingrained biases of senior engineers, provided there's a senior culture that embraces dialogue and validation.

The rise of AI tools presents a new frontier, potentially exacerbating the knowledge loss problem if not managed carefully. While these tools can accelerate development, they risk becoming black boxes that bypass the crucial human process of building tacit knowledge. The challenge, then, is to integrate these tools in a way that complements, rather than replaces, the human capacity for learning and adaptation, ensuring that knowledge is retained and transferred.

Key Action Items

• Prioritize Post-Deployment Learning: Schedule dedicated time (e.g., two weeks post-launch) to analyze production data and user feedback for every significant deployment.
• Foster Tacit Knowledge Transfer: Implement structured practices for knowledge sharing, such as pair programming, internal tech talks, and mentorship programs, especially when experienced team members are transitioning roles or leaving.
• Embrace Minimal Viable Architecture: Focus on building only what is needed for the current problem, but ensure the design makes it easy to evolve. Avoid speculative over-engineering.
• Assume You're Wrong: Cultivate a team culture where questioning assumptions and accepting that initial implementations may be flawed is encouraged, not penalized.
• Integrate Diverse Skill Sets: Actively seek to build teams with a mix of technical expertise, design thinking, and other relevant disciplines to foster innovation and holistic problem-solving.
• Make Hard Things Easy to Change: Identify architectural decisions that are typically difficult to alter and proactively implement strategies or tooling to mitigate that difficulty (e.g., evolvable database schemas, flexible service boundaries).
• Leverage AI as a Tool, Not a Crutch: Use AI for code generation and analysis, but ensure that the human team remains deeply involved in understanding the system's behavior, learning from its operation, and retaining that knowledge. This pays off in 12-18 months by preventing knowledge silos and ensuring system resilience.