Recently I re-read The Mythical Man-Month and one section resonated with me. It described how an architect of a software development system should deal with the people that develop his or her vision. I think it defines The Humble Architect.

As we all know from experience, having someone tell you how to do your job can feel like an attack. It can make you feel defensive. This holds true in a lot of situations including the software development world.

Any time someone suggests that your way of developing or designing a piece of software isn’t as good as their way, you naturally want to defend your work. I often feel this way when the architect of the system I am working on critiques my work and wants me to change the approach I’ve taken. Knowing how that feels hopefully makes me empathize with other developers when I offer the same advice on their work.

When recently reading The Mythical Man-Month by Frederick Brooks, he described a scenario when an architect challenges the estimate given by a developer charged with implementing the architect’s designs. If the developer comes up with a higher estimate, the architect owes it to the developer to offer a possible implementation. That way, the developer can understand what the architect had in mind and how they formulated their estimate.

This sort of interaction occurs all the time. Not only between architect and developer, but between all members of a team developing software. But challenging a developer’s approach (and resulting estimate of effort) can be, as Brooks states, “an emotion-generating activity”. How does one defuse this situation and avoid conflict?

Brooks proposes that when an architect “challenges the builder’s way of doing the builder’s job”, the architect must:

  • remember that the builder has the inventive and creative responsibility for the implementation; so the architect suggests, not dictates;
  • always be prepared to suggest a way of implementing anything he specifies, and be prepared to accept any other way that meets the objective as well;
  • deal quietly and privately in such suggestions;
  • be ready to forgo credit for suggested improvements.

I offer this is a good initial description of The Humble Architect. Such an architect is good at designing software solutions, to be sure. But more than that, the Humble Architect is capable of communicating their vision and working with the builders to achieve that vision. They treat the builders with respect and are humble in their approach to giving feedback and suggestions. And just as important, they are open to recognizing the contributions others have to the overall design and the success of the project.

I have met a few Humble Architects in my career. I always admired their style and approach to interacting with their co-workers. It is something I strive to embody when I interact with my co-workers. I find it difficult sometimes to make suggestions without having to dictate solutions. Sometimes I get a vision in my head of what a solutions should be and I get passionate about seeing it implemented. When a co-worker does not implement it the way I envisioned it, I can get upset. But as Brooks pointed out, you must be prepared to accept any solution as long as it meets the objectives. I’m still working on that one.

But I feel I do a good job of working with my co-workers to negotiate and agree to a solution. I always make such associations in private as I find it the best way to discover what the other person is thinking. More often than not I learn from those exchanges and the final solution is better for it. And I don’t think I could sleep at night if I took any credit for ideas that I learned from someone else. We succeed as a team, but each of us deserves credit for their contributions.

While I am not the ideal specimen, I attempt every day to become a Humble Architect. Shouldn’t we all?