When interviewed for a promotion some time ago, the interviewer told me two developers are arguing over whether to use programming language A or B for a project and asked me which I would recommend.
There are different ways to answer the question. The first is technical, comparing the language minutiae, libraries, IDEs and tool support. It argues the merits of the vendors, communities behind the languages and often has a bias toward favourite languages or tools.
Team leaders and managers approach the problem differently. They look at the existing skills of the team. They look at support structures (such as contracts and consultants), the longer term viability of languages and their organization’s investments in each. They consider the risks and benefits.
I gave both these answers. While correct, these answers miss a critical viewpoint: customer benefit. For example, the product may have to integrate with existing applications using mechanisms only supported by or heavily geared toward certain languages, like COM with C++, Visual Basic or C#. The target device or operating system may support one primary language, such as iOS and Objective-C. Languages may have runtimes that require additional configuration and patching, such as Java or Flash, and the customer lacks the infrastructure and expertise.
Customer benefit is an assumption so implicit in the question that people consider it assumed or ignore it. However, this assumption is what makes the question a great (trick) question, particularly for a software architect that needs to interpret, challenge and identify requirements.
“We do not see things as they are. We see them as we are.” Talmud
Moving from a developer to an architect involves a change in perspective. Developers leap to details with the “how”, arguing libraries or techniques. Managers identify resource requirements and risk. Architects step back and ask “Is this even the right question?”
“Nothing is more dangerous than an idea if it’s the only one you have.” Emil-Auguste Chartier
Thinking inside the box is easy. Thinking outside the box is hard. Finding the box is harder still. Architects may specialize but are expected to delve into enough detail to validate a proposed solution without risking leaping to conclusions or becoming too attached to a solution. Developers focus on the best and fastest way to solve a given problem.
“The limits of my language is the limit of my world” Ludwig Wittgenstein.
Design patterns are useful for conceptualizing and communicating designs. Understanding the business problem and customer viewpoint is critical to identifying the best solutions. Architects straddle both the developer and customer worlds and so must learn the terminology of both and translate concepts between them.
“It takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!” Lewis Carroll
It is an understatement to say technology changes rapidly. Whereas developers must keep up with their chosen tools and languages in detail, architects evaluate and adapt to a wider set of technologies but less deeply than a developer, particularly those architects responsible for a technical strategy or vision.
“It is a painful thing to look at your own trouble and know that you yourself and no one else has made it.” Sophocles
Architects are responsible for the product without being the ones implementing it, including design delegated to others and trade-offs made to handle technical or business constraints, and their role is as much communication and evangelism as high level design. Managers have long been accustomed to this level of responsibility and facilitation but it may be new to a developer.
Of course, this is not to say a developer cannot think like an architect or manager (or other permutations) or that these are immutable, defined roles. Like Edward de Bono’s Six Hats, recognizing that there are different viewpoints and switching between them is key. It is also challenging, particularly when under the pressures of commercial software development. Or an interview.
Anthony Langsworth
@alangsworth
anthonylangsworth
Random Acts of Architecture 
Conflict resolution is, in my opinion, one of the central business justifications for an architecture team. Very little is more destructive than “irreconcilable differences” between two engineers (or worse, two engineering groups).
Your three answers here focus on what is “right” (from a few different angles). And this is critical, but the engineer who was “wrong” isn’t going to feel great about it, and it is generally useful to take additional steps to avoid any unnecessary consequences.
It might be as simple as a really good explanation and appeal. It may be a compromise of some sort (such as making an exception for some subsystem, assuming that that is appropriate and the foundation of the engineer’s concern). It may even need some kind of “avoidance strategy”, such as moving that engineer into a different team.
Thanks for writing these – I’m really enjoying them.
That’s a good point about a central architect or architect team being a point of conflict resolution. This is a whole other area, perhaps a future blog post.
One of the challenges dealing with senior developers, particularly those that subscribe to the “craftman” mindset where their goal is to be recognised as good by their peers, is their designs and code form part of their identity. Spending time discussing them is often “wasting time” when the solution is “obvious” and criticizing their design may be like calling their baby ugly.
Sometimes it is worth giving in to minor issues. Sometimes it is a case of sitting down and talking through the requirements (some of which may be unknown to either or both parties) or other possibilities (since more experienced developers tend to leap intuitively to a design but may have difficulty supporting it or thinking of others). As you say, both parties could be wrong and the solution may be neither or a combination of both.
I’m glad you are enjoying the blog, too.
I really enjoyed this post and can relate very much to the points made as I have been transitioning to an architecture role after being a developer in the same company. Coming from a development mindset (and knowing the code base) has made the transition much more difficult due to the habit towards details. I’ve found it easier to step out of the code completely for four months to focus on building the skills of architecture, and facilitating rather than looking at code.
Great posts, keep them coming.
The transition is hard, isn’t it? It is all too easy to get back to the code level, particularly if someone is working on part of the product you used to own. Learning to trust developers is hard at first, particularly when you are responsible for their work, but it frees you up to think about strategic and higher level things.
Thanks for the kind words, too. I’m glad you like the blog.