Dustin Marx is a software developer who enjoys identifying and using the correct tool for the job. In addition to writing software and writing a blog on software development, Dustin occasionally presents at conferences and writes articles. Dustin is a DZone MVB and is not an employee of DZone and has posted 229 posts at DZone. You can read more from them at their website. View Full User Profile

Software Architects Need Not Apply

06.27.2012
| 3502 views |
  • submit to reddit

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 has written that Those Who Can, Code; Those Who Can't, Architect (beware an extremely obnoxious Flash-based popup) and has stated that part of his proposed Hippocratic Oath for Programmers would be to "swear that my desire to enter the computing profession is not to become an architect." Andriy Solovey has written the post Do We Need Software Architects? 10 Reasons Why Not and Sergey Mikhanov has proclaimed Why I don’t believe in software architects. More recent posts have talked of Frustration with the Role and Purpose of Architects on Software Projects and The frustrated architect. 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 ("The Second-System Effect") The Mythical Man-Month, Frederick P. Brooks, Jr., 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 was published more than 35 years ago in 1975, 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 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. 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 (DRY) and You Ain't Gonna Need It (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.

Published at DZone with permission of Dustin Marx, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Greg Brown replied on Thu, 2012/06/28 - 8:15am

I know some people view architecture as a design-only role, but I've never personally agreed with that perspective. I've always considered an architect to be a developer who is responsible for the design of a system. As an architect myself, I don't think it is possible to produce a good design if you are not involved in the implementation.

 

Mark Unknown replied on Fri, 2012/06/29 - 8:44am

The problem with what most people see is wrong with a software architect is the same thing that is wrong with Software Managers, BAs and PMs.  It is not a "graduation" or promotion process. You don't go from entry level programmer to junior to senior to lead to architect to manager/pm/ba.  Those things require different skill sets and, most importantly, ability.  Sometimes they are just roles and not jobs.  Moving to management is not a promotion - it is a  career change.

Back to software architect:  They must be hands on. They cannot be coding 24/7, though. They probably are NOT the best coder. They need to listen to the "non-architects" because one cannot know/experience everything and/or there might be a budding (or existing) architect.  But at the same time, someone needs to see the bigger picture. Whether you have a role or title of architect or not - you must have one (or more). And you better hope you have a good one.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.