Architects Should Code: Debunking the Ivory‑Tower Misconception

When interviewing candidates for architect positions, interviewers often ask whether architects should still write code, receiving answers ranging from a desire to stop coding entirely to a willingness to code only a little. These responses raise concerns about the point at which a technical role becomes detached from implementation.

Feedback

Architects who are deeply involved with delivery teams receive first‑hand feedback on changing standards, evolving functional and non‑functional requirements, and challenges discovered during implementation and testing. Early detection of defects enables faster architectural improvements, reduces technical debt, and keeps projects agile.

Leadership

Beyond design, architects must provide technical leadership by communicating the big picture, mentoring developers, and fostering a shared vision through continuous collaboration rather than relying solely on documents or presentations. Effective leadership also involves teaching non‑technical skills such as agile principles, architecture modeling, and collaboration with diverse stakeholders.

Strategies to Increase Involvement

Pair Programming : Working side‑by‑side with a developer on a shared workstation keeps architects accountable for delivery and provides immediate feedback while avoiding resource drain.

Peer Review : Reviewing code with developers, either regularly or before story completion, gives architects deep insight into architectural consistency and an opportunity to influence decisions.

Development Scouts : Forming a small “scout” team to explore new technologies, prototype concepts, and assess risks offers architects hands‑on experience and rapid feedback on architectural choices.

Story Development : Occasionally taking on actual story work creates the tightest feedback loop, though architects must balance detailed work with maintaining a broader architectural vision.

Rotation : Rotating the architect role among team members spreads architectural knowledge, improves cross‑role empathy, and can boost overall product quality, provided the rotation cadence is carefully managed.

Practices to Avoid

Only Solving Hard Problems : Exclusively tackling the toughest issues deprives the team of learning opportunities and can isolate the architect from the rest of the system.

Takeover : A command‑and‑control approach that tries to own the entire delivery process creates resentment, stifles team autonomy, and hampers scaling.

Focusing on Details Over Essence : During pair programming or reviews, architects should guide the underlying intent rather than dictating every line of code, allowing developers to apply standards while preserving flexibility.

Conclusion

Successful architecture requires continuous, close collaboration with delivery teams to maintain rapid feedback loops, share the architectural vision, and provide leadership. By engaging in coding activities such as pair programming and peer reviews—and avoiding ivory‑tower isolation—architects can better identify and resolve architectural flaws early, leading to healthier projects and products.

About the Author

Brandon Bryson is a senior advisor at MasterCard, focusing on application architecture, development, and agile delivery. With 15 years of experience across defense, travel, supply chain, and finance, he holds a computer science degree from the University of Missouri.