Software Architects Need Not Apply

I saw an online job posting several years ago that listed a set of desired software development and programming skills and concluded with the statement, "Architects Need Not Apply." Joe Winchester [1] has written that Those Who Can, Code; Those Who Can't, Architect [2] (beware an extremely obnoxious Flash-based popup) and has stated that part of his proposed Hippocratic Oath for Programmers [3] would be to "swear that my desire to enter the computing profession is not to become an architect [4]." Andriy Solovey has written the post Do We Need Software Architects? 10 Reasons Why Not [5] and Sergey Mikhanov [6] has proclaimed Why I don’t believe in software architects [7]. More recent posts have talked of Frustration with the Role and Purpose of Architects on Software Projects [8] and The frustrated architect [9]. In this post, I look at some of the reasons software architects are often held in low esteem in the software development community.

I have been (and am) a software architect at times and a software developer at times. Often, I must move rapidly between the two roles. This has allowed me to see both sides of the issue and I believe that the best software architects are those who do architecture work, design work, and lower level implementation coding and testing.

In Chapter 5 [10] ("The Second-System Effect [11]") The Mythical Man-Month [12], Frederick P. Brooks, Jr. [13], wrote of the qualities and characteristics of a successful architect. These are listed next:

• An architect "suggests" ("not dictates") implementation because the programmer/coder/builder has the "inventive and creative responsibility."
• An architect should have an idea of how to implement his or her architecture, but should be "prepared to accept any other way that meets the objectives as well."
• An architect should be "ready to forego credit for suggested improvements."
• An architect should "listen to the builder's suggestions for architecture improvements."
• An architect should strive for work to be "spare and clean," avoiding "functional ornamentation" and "extrapolation of functions that are obviated by changes in assumptions and purposes."

Although the first edition of The Mythical Man-Month [14] was published more than 35 years ago in 1975 [15], violations of Brooks's suggestions for being a successful architect remain, in my opinion, the primary reason why software architecture as a discipline has earned some disrespect in the software development community.

One of the problems developers often have with software architects is the feeling that the software architect is micromanaging their technical decisions. As Brooks suggests, successful architects need to listen to the developers' alternative suggestions and recommendations for improvements. Indeed, in some cases, the open-minded architect might even be willing to go with a significant architectural change if the benefits outweigh the costs. In my opinion, good architects (like good software developers) should be willing to learn and even expect to learn [16] from others (including developers).

A common complaint among software developers regarding architects is that architects are so high-level that they miss important details or ignore important concerns with their idealistic architectures. I have found that I'm a better architect when I have recently worked with low-level software implementation. The farther and longer removed I am from design and implementation, the less successful I can be in helping architect the best solutions. Software developers are more confident in the architect's vision when they know that the architect is capable of implementing the architecture himself or herself if needed. An architect needs to be working among the masses and not lounging in the ivory tower [17]. Indeed, it would be nice if the title "software architect" was NOT frequently seen as an euphemism for "can no longer code."

The longer I work in the software development industry, the more convinced I am that "spare and clean" should be the hallmarks of all good designs and architectures. Modern software principles seem to support this. Concepts like Don't Repeat Yourself [18] (DRY) and You Ain't Gonna Need It [19] (YAGNI) have become popular for good reason.

Some software architects have an inflated opinion of their own value due to their title or other recognition. For these types, it is very difficult to follow Brooks's recommendation to "forego credit" for architecture and implementation improvements. Software developers are much more likely to embrace the architect who shares credit as appropriate and does not take credit for the developers' ideas and work.

I think there is a place for software architecture, but a portion of our fellow software architects have harmed the reputation of the discipline. Following Brooks's suggestions can begin to improve the reputation of software architects and their discipline, but, more importantly, can lead to better and more efficient software solutions.