Why Architects Who Haven’t Coded in Years Miss Critical System Realities

Why This Remark Reveals a Problem

During a 2022 technical design review, a programmer presented a solution when an architect interrupted, asking why a message‑center approach wasn’t used instead of calling a third‑party API directly. The author immediately thought the architect was a "PPT architect" who lacked real‑world understanding.

The architect’s comment exposed three missing facts:

The system has no message center at all; building one from scratch requires protocol design, reliability, monitoring, operations, cost estimation, and adoption effort.

Creating a foundational service cannot be tacked onto a single business feature; the review focuses on the feature’s technical solution, not on a whole‑system evolution plan.

The architect has not touched code for a long time, so he lacks awareness of the current system’s components, gaps, and the need for dedicated projects.

Moreover, if the architect truly valued a message center, he would either know it is already planned or would proactively initiate a project, rather than raising the issue spontaneously during a review.

The Foundation of Architecture Design Is Understanding the Code

Effective architecture requires judging the system’s present state and deciding its future direction. Knowing what exists, what is missing, where coupling is heavy, which parts change frequently, and what historical baggage remains are insights that rarely appear in documentation but are embedded in the code.

For example, determining whether two modules can be split into independent services demands inspecting actual code coupling, shared database tables, and intertwined logic—knowledge only obtainable by writing, modifying, or reading the code.

Thus, architects must continuously write and read code; relying solely on second‑hand information yields an incomplete view.

Architecture decisions rest on accurate assessment of the current state, and that assessment comes from the code.

What Guides Architecture When Detached from the Frontline

If an architect no longer writes or frequently reads code, their judgment falls back on two sources: industry best practices and past experience.

Industry practices are context‑specific; what works for another team may not suit yours due to differences in team size, business model, codebase, and legacy constraints.

Past experience also ties to the system at the time it was gained; after years of code, business, and team changes, previously effective solutions may no longer apply.

Therefore, while referencing external practices and past lessons is acceptable, they cannot replace a deep understanding of the current code.

Such suggestions often surface in review meetings because, for architects who rarely engage with code, the meeting is the only venue where they encounter concrete system details.

The core issue is not that the advice is wrong, but that conclusions are drawn without sufficient knowledge of the existing system.

How to Maintain Awareness of Implementation

Practical actions for staying connected to the codebase include:

Consistently participate in code reviews, especially for core modules, and listen more than you speak.

Periodically examine recent changes in critical modules; you don’t need to read everything—focus on areas with many modifications to gauge business direction.

When adopting a new technology component, build a small prototype yourself to assess usability and compatibility with the existing stack.

Take part in the development of key modules.

Frequently investigate production incidents; real‑world failures reveal system behavior, pain points, and areas prone to issues.

Conclusion

This challenge isn’t limited to architects; as programmers mature, they increasingly contribute to design and review, eventually offering the same kind of feedback.

The usefulness of their input depends heavily on whether they still understand the system’s current state.

Code won’t design the architecture for you, but it will reveal the system’s true nature.