Why Should Software Architects Write Code?

By Mehdi Mirakhorli (@MehdiMirakhorli), Associate Editor.

In the software engineering community there is a divide on who needs architects, what responsibilities should architects have, and whether architects should code. We all have heard these questions in one form or another, all motivated by a wide range of pragmatic opinions. Some practitioners argue that architects responsibility is for the integrity of the entire system, and satisfying business goals while mitigating the risks; Therefore, architects can postpone other lower-level decisions, including the coding decisions, to developers that typically have more limited responsibilities. On the other side of this spectrum, a group of practitioners argue architects should code. Some critics even take the criticism of “architects not practicing coding” further and argue that: “powerpoint architects'' are ineffective while expensive to afford. These architects join the project kickoff meetings, draw all sort of diagrams and leave before implementation starts.  They are ineffective because of their absence and lack of ongoing feedback during the development cycle. We should also keep in mind that, such disconnection will create more problems considering that the requirements which the same architecture addressed will more likely change later on.

Other practitioners choose a moderated perspective. In his recent keynote talk, Martin Fowler explores different ways of stimulating collaboration and communication between programmers and architects, and he advocates the idea of architects pair-programming with developers. Ward Cunningham in an anti-pattern called “Architects Don't Code'' addresses the same issue---  that  “The Architect responsible for designing your system hasn't written a line of code in two years''. Ward recommends getting architects involved at the implementation level.

In his new book, “Software Architecture for Developers'', Simon Brown advocates a transition from architects as “ivory tower'' to a role which is about coding, coaching and collaboration. All these practitioners agree on the necessity of having some form of architecture design. Simon Brown argues that most software developers are not architects or do not have extensive design skills. Therefore, he advocates increasing the design knowledge of developers as a way to bridge the gap.

These discussions are just a few samples of pragmatic perspectives. Following either of these opinions largely depends on having the necessary trust in the person advocating it. 

While there have been numerous studies about the impact of architecture in a software system, there has not been an empirical study to examine the influence that software architects can have during coding activities of a software system. In our research we use mining software repository techniques to answer the question of Why should architects write code?

We studied the architecture and implementation of six software systems. In these case studies we looked at the involvement of developers in implementing architectural patterns/tactics (e.g. authentication, audit trail, thread pooling, scheduling).

Observation 1: Developers have more difficulty implementing the architectural choices (e.g. patterns/tactics) than functional features.

The developers contributing to these projects were observed to have difficulties implementing architectural tactics. The tactical files for all of these projects underwent more refactoring efforts than non-tactical files and contained more defects. In fact, from November 2008 through November 2011, 2.8 times as many defects were found in tactical files than non-tactical files for the Hadoop project, while from January 2009 through November 2011, 2.0 times as many defects were found in these files for the OFBiz project.

Following this observation, we formulated the following hypothesis: When software architects write code, the number of defects in the tactical fragments of the systems will be reduced.

To examine this hypothesis, we conducted a second study to examine the impact that architecture-savvy and non-architecture savvy developers have on defects in design fragments of a system.

We divided the source code commits into architecturally-significant commits and functional commits. Code changes impacting the architectural patterns/tactics were classified as architecturally significant while those commits only impacting the functional features of the system were labeled as functional commits. Then we created a profile for each developer involved in the implementation of tactics. We used a persona-based human modeling approach to extract the architecture and design experience of the developers from the six software projects. For each developer, we created a profile to document his/her design expertise. Next, these profiles were categorized into architecture-savvy and non-architecture-savvy personas. Using these profiles, we created a design contribution matrix, examining the relationship between developers design backgrounds and defects in design fragments. In this post, I report a some of the results of our study and what we observed across these six projects.

Observation 2: Non-architecture savvy developers introduce more defects into architecturally-significant code snippets than architecture-savvy developers.

Overall in four out of six projects, we have strong statistical results, validating our research hypothesis. This provides empirical evidence on why software architect should write code or, at least, be engaged in the development of tactical fragments in a system. Developers with little or no background in architecture and design struggled to implement architectural patterns/tactics. The majority of the defects in the tactical files were introduced because of a misinterpretation of the design concept, being unaware of the rationale for the tactic, or just plainly implementing it incorrectly.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I am looking forward to read your comments and feedback on this post. Also I would like to encourage researchers and practitioners to conduct similar empirical studies to examine the controversial pragmatic opinions related to Architecture and Coding.

Next post is going to summarize a few practices to bridge the gap between design and implementation. Stay tuned!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You may also like:

Buschmann, F.; Bartholdt, J., "Code Matters!," in Software, IEEE , vol.29, no.2, pp.81-83, March-April 2012.

Frank Buschmann, "Introducing the Pragmatic Architect," IEEE Software, vol. 26, no. 5, pp. 10-11, September/October, 2009.

Fowler, M., "Design - Who needs an architect?," in Software, IEEE , vol.20, no.5, pp.11-13, Sept.-Oct. 2003.

Paul Clements, Mary Shaw, ""The Golden Age of Software Architecture" Revisited," IEEE Software, vol. 26, no. 4, pp. 70-72, July/August, 2009.

Acknowledgement:
"This post includes joint work with Inayat Rehman, Matthew Thornton and Azat Aralbay Uulu, graduate students at RIT. I would like to thank Mei Nagappan for crunching the numbers for the experiment reported in this blog."