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.