Should an architect code?

For those interested, the role of an architect is –also- being discussed in MSDN, here. My first reply next:

The answer depends on what do you mean by “architect” (noun) and also by “code” (verb).

What seasoned designers talk about when discussing architecture is so all-encompassing and important for the final outcome that makes me wonder why a project team member wouldn’t need to fully master the actual concretization of such concepts at all levels? I suspect the answer is related to the sad state of practice in many organizations due to the faulty belief that the main task in writing software is a mechanical and repetitive task that can be industrialized with expendable and interchangeable human ‘resources’.

See: Discussing uncomfortable questions

Pursuing a clear definition of a concept like architecture is good because the related thinking-researching cycles give opportunity to reach sound conclusions (by ‘sound’ I mean -inferences with scientific properties like provisional and falsifiable). I have not yet found a satisfactory definition for what architecture in computing really means, far less a definition of what the role of an architect could possibly be. By now, the proposal by Frederick Brooks, Jr. for the concept of architecture is arguably the most sensible definition I have found:

“Computer architecture, like other architecture, is the art of determining the needs of the user and then designing to meet those needs as effectively as possible” –Oxford English Dictionary

Why? Because it explicitly includes three key concepts: art, user needs, and design.

A discussion about the design concept would be in order to answer the question: “Should an architect code?”

So, if by code, do you mean executing a mechanical and repetitive task that can be industrialized? Then the answer is ‘no’ (and also ‘no’ for any self-respecting software professional by the way).

On the other hand, if by code, do you mean the act of expressing design intentions and the execution of models to corroborate hypothesized ideas with contextual data? Then the answer is ‘yes’ (and also ‘yes’ for any self-respecting software professional by the way).

Next, I quote a thinker whose name I don’t know (if the author is listening, see: What type of person should design software? ).

"There are certainly people who think more about high level structure than they do about low level details. This is a valuable talent, and not one that should be scoffed at or discounted. Unfortunately, in some circles, it has become popular for people with these talents to divorce themselves from code. The term "architect" takes on an aura of authority and power, whereas a coder is deemed a lowly laborer, a dime-a-dozen worker bee.

In reality, while the difference in talent is real, the polarization into different roles with different authorities is harmful. Those folks who are good at modeling and architecture must still remain grounded in code. For their skills to remain relevant and useful, they have to keep in touch with the medium they are trying to create structures for. Likewise, the programmer who divorces himself from concerns of architecture harms himself and his team by abdicating responsibility for something he is in an intimate position to control. There is a way for these two talents to work well and closely together, but they have to put forth the effort to understand each other."

More notes about the practice of architecture:

Software architecture is much more than structure

Architecture is not about scalability, not even about user, it is all about usage

Comments

• Anonymous
  June 17, 2018
  Thank you very much for this tips. Thank you