Software Architect: This Is How You Design Systems That Survive
TL;DR
Shipping is the starting line, not the finish line — Nico Krijnen says the real learning starts after production, and teams should revisit shipped work 2 weeks later to inspect data, user behavior, and operational surprises instead of blindly moving to the next story.
The core engineering skill is broad problem solving under real-world feedback — after 30+ years, Krijnen argues the job is less about writing code and more about diagnosing failures, following curiosity into unexpected behavior, and improving systems once reality proves the first solution wrong.
Great systems come from mixed teams, not just strong programmers — he points to his early-2000s web work where designers imagined impossible browser experiences and engineers made them real, plus later teams that even pulled in a growth hacker when product launch demands required it.
A system becomes legacy when the people who understand it are gone — Krijnen’s blunt test is simple: if the original team has left, nobody wants to touch it, bug fixes are scary, and tacit knowledge has evaporated even if the code and docs still exist.
AI can accelerate coding while quietly destroying system understanding — he worries that remote work plus agentic tools can produce lots of software without helping humans build the tacit, experiential knowledge needed to maintain and evolve it later.
Design for change by assuming you’re wrong — instead of overengineering for futures that may never come, Krijnen recommends building the minimum that works now, tightening feedback loops, and making change cheap so architecture evolves from evidence rather than speculation.
The Breakdown
Why he keeps coming back to hands-on engineering
Krijnen opens with a career arc a lot of senior engineers recognize: software engineer to architecture, agile, management, then back to coding. His big point is that pushing strong technical people into management by default is often a waste, especially when their real superpower is solving hard socio-technical problems with "their feet in the mud." He recalls a crisis where three senior engineers fixed a brutally complex problem in three weeks — a reminder that his highest leverage was still deeply technical.
The real job: solving problems after the code ships
For Krijnen, the defining skill is not coding speed but pattern recognition: seeing where things break because you’ve seen enough systems fail before. He keeps coming back to the idea that production is where software gets interesting, because that’s when reality — weird data, user reactions, unexpected behavior — tells you what the system actually is. His frustration is that many teams treat deployment as “done,” when in his view that’s exactly when the learning should begin.
Curiosity needs a trigger, and teams rarely build one in
He describes curiosity as something that can come naturally with exciting work, but often needs to be deliberately provoked by looking at real data and noticing something that doesn’t fit your assumptions. His practical suggestion is simple: after a story ships, come back to it later and inspect what happened. That habit, he says, is missing in teams under constant pressure to ship, even though it’s the mechanism that turns delivery into learning.
The best products come from weird combinations of people
One of the liveliest stories is from his early full-service web agency days around 2000, when designers dreamed up wild interfaces that browsers absolutely did not want to support. Instead of saying no, the engineers hacked around Netscape-era limits — full-screen popups, fake window chrome, custom close buttons — and made “crazy shit” work. That experience shaped his view that successful teams need specialists, generalists, and adjacent disciplines like design, UX, marketing, or even a growth hacker, depending on the moment.
Juniors contribute more than seniors think
Krijnen pushes back hard on the idea that junior people mainly receive and don’t give much back. He says newer engineers bring contagious energy, fresh eyes, fewer inherited assumptions, and often surprisingly useful things — down to a shortcut he immediately stole from a younger teammate and put on a sticky note. More importantly, they challenge stale mental models and can expose when “this is how it works” is just old baggage.
Getting stubborn seniors to actually listen
He’s realistic that experience can harden into bias, including his own, so he tries to treat his ideas as no more sacred than anyone else’s. His tactic for strong personalities is structured collaboration: silent idea generation, sticky notes, and methods that surface everyone’s thinking before the loudest voice dominates. The deeper move is empathy — understanding that stubbornness comes from past experience, then creating experiences or conversations that help people update without feeling attacked.
What makes systems survive — and what makes them legacy
On architecture, Krijnen references Barry O’Reilly’s idea of stress-testing systems with bizarre scenarios — even “fire-breathing lizards in your data center” — to discover what survivability components are missing. But the strongest section is about legacy: he draws on Peter Naur’s 1985 “programming as theory building” idea to argue that code and documentation are not enough. The real maintainability asset is tacit knowledge in people’s heads, and once the team that built the system is gone, the software may still run but it’s already drifting into legacy territory.
Why AI may speed up coding while making systems more fragile
That leads straight into his warning about agentic AI. He likes the tools, but says they don’t yet accumulate the lived, consequence-shaped knowledge humans get from building, operating, and debugging production systems. Add remote work, less human pairing, and black-box code generation, and you risk faster output with weaker shared understanding — exactly the recipe for systems that become legacy sooner.
The balancing act: don’t overengineer the future
In the closing stretch, he tackles the classic architecture trap: adding flexibility early for a future that may never arrive. He admits he’s built elegant, generic systems that turned out to be unnecessary complexity, and says the better pattern is to assume your first design is wrong, build only what you need now, and optimize your feedback loop. His north star is simple but sharp: make code easy to change, because that beats pretending you can predict the future.