A Conversation with Luke Hohmann, Part III

Luke Hohmann is a management consultant who helps his clients bridge the gap that often exists between business and technology. In his past experience, he has played many of the varied roles required by successful software product development organizations, including development, marketing, professional services, sales, customer care, and business development. Hohmann currently focuses his efforts on enterprise class software systems. He is the author of Journey of the Software Professional: A Sociology of Software Development (Prentice-Hall, 1997), which blends cognitive pyschology and organizational behavior into a model for managing the human side of software development. He is also the author of Beyond Software Architecture: Creating and Sustaining Winning Solutions (Addison-Wesley, 2003), which discusses software architecture in a business context.

On March 8, 2004, Bill Venners met with Luke Hohmann in Sunnyvale, California. In this interview, which will be published in multiple installments on Artima.com, Hohmann discusses software architecture in the context of business.

• In Part I: Growing, Pruning, and Spiking Your Architecture, Hohmann discusses architecture and culture, the importance of completeness in new architectures, and implementing features in spikes.
• In Part II: Entropy Reduction, Hohmann discusses entropy reduction, the cost of change, and programming as choreography.
• In this third installment, Hohmann discusses entropy reduction, the cost of change, and programming as choreography.

Mapping Architecture to Human Needs

Bill Venners: In Part I of this interview, you said that an architecture is good to the extent it is fit for the uses to which it is applied. To what extent does an architecture also need to fit the team that's working on it?

Luke Hohmann: This is loosely called Conway's law. In a paper published in 1968, Melvin Conway wrote:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

I like to extend Conway's law to talk not just about communication structures, but also about human need.

For example, as a manager I once had to choose between two competing architectures for a project that was to be built by two teams, one in Germany and one in the U.S. In the first option, the U.S. team would do requirements analysis, design, and implementation of the architecture, and German team would build a component that fit within that architecture. In the second option, both teams would do architectural analysis, design, and implementation, and then we'd link up the two subsystems through a well-defined API. I chose the second option, because the team in Germany was used to doing architectural-level analysis, design, and implementation. I think an architecture needs to honor a large degree of human desires and motivations beyond just the communication constraints that are talked about by Conway's law.

Another aspect of matching architecture to human needs is matching roles and responsibilities of the people building a system to the appropriate parts of the architecture. Some pundits say that everyone likes to do everything, but that's not true. I suspect that a lot of people who write about architecture, although they are very smart, have never managed large teams. I've managed a 60-person team, and I personally know UI guys who would never get near a database, because they think databases are "stupid". And I know many database developers who would never go near a UI. The last thing these database people want to do is the full architectural stack. They've spent their life becoming an expert at Oracle. And you know what? They are an expert at Oracle. They aren't going to be an expert at UI design, and given what they would normally design for a UI, you wouldn't want them to be touching the UI anyway. When you look at the stack in your architecture, and then you look at this mass of people on your team, the architecture and the people have to match. Otherwise you'll have problems.

Choosing Languages for Social Reasons

Bill Venners: You write in your book, Beyond Software Architecture:

It is vitally important to understand how your team wishes to develop their product. Surprisingly, I've worked with teams that completely reject agile methods because they consider them the domain of "hacks" who don't know how to specify and build reliable software systems. These teams demand MRDs [Marketing Research Documents] and related documents; they have a process and they follow it. As you can guess, I adjust my own preference for agile processes to meet their needs. Forcing a given team to adopt an approach that they don't believe in, either in their development process or in the language they're using to create the system, is a certain recipe for failure.

My experience has been that the "right" choice—the right architecture, the right method, the right language—has much to do with the situation. The individual personalities, the history, the team culture, the particular business situation impacts the decision as much as straight technical concerns.

Luke Hohmann: Most people tend to kid themselves that languages are chosen for technical reasons. Languages are chosen for social reasons and justified for technical reasons. No one genuinely picks a given language for purely technical reasons. Why do you want to use a given language? Maybe you're tired of using C, or you're tired of using Cobol. You want to use the next language. It looks cool. You want to pad out your resume. You want to future proof yourself.

Many of the reasons to choose a new language have nothing to do with economic reality or technical need. One way to respond to that is to try to fight it and make people choose the language for technical reasons. The other way to respond is what I do when I work with a team. I say, "OK, it looks like you have some choices to make about your architecture. Now, we could kid ourselves and fool ourselves into thinking we're making these decisions technically, but since we're behind closed doors, and since I am a consultant, so you can tell me anything, why don't you tell me what you would like to learn, what you think is cool, what you are interested in, and then we can see how far away those are from the real business needs." Suppose someone says, "Oh, what I really want to do is learn Smalltalk". The other people on the team might say, "That's stupid. Smalltalk is a dead language. Who wants to learn Smalltalk?" So Smalltalk is not necessarily the best choice for that team, but at least you're talking about it in an up-front way.

Bill Venners: How prevalent is resume-driven design, choosing a technology based on what will pad out your resume?

Luke Hohmann: More prevalent than managers would expect, I'm sure. I've had to kill some projects that were just horrendously resume-driven design. My favorite example was a J2EE monstrosity for doing something that a relatively simple set of Perl scripts could have handled. I just walked in and said, "We can't fix it. We have to kill it." It was millions of dollars down the drain. A complete waste. I'm faced with that same situation with one of my clients right now. They're embarking on what looks to be a really big J2EE project, and they're absolutely convinced that this is the right thing for them to do. If someone would say, "The reason I want to do J2EE is because I want to learn it," it would at least make some sense to me. As near as I can tell, though, J2EE has absolutely no value for what they're doing. But neither would .NET or any other über-technology. They just don't need that kind of huge infrastructure.

Bill Venners: It's not only in the interest of the developers to be working with resume-enhancing technologies. Language and technology choices affect management's ability to keep the people they have and attract new people.

Luke Hohmann: I agree. That's another way languages are chosen for social reasons, and justified for technical reasons. If you tell a candidate that you wrote your system in Smalltalk, they might think, "If I take this job, it's a dead-end career move for me." If you as a manager are justifying your technology choices based on the idea that you're going to have to hire a replacement or bring a future developer on, that's fine. You've not made the choice technically. You've made it socially, and that's OK. That's a very fair way to make the choice.

The Appropriate Architectural Granularity

Bill Venners: In your book, Beyond Software Architecture, you write:

One of the key challenges associated with loose coupling concerns component granularity. By granularity I mean the level of work performed by a component. Loosely coupled components may be easy to understand, test, reuse, and maintain in isolation, but when they are created with too fine a granularity, creating solutions using them can be harder because you have to stitch together so many to accomplish a meaningful piece of work. Appropriate granularity is determined by the task(s) associated with the component.

How to you determine the appropriate granularity of a design?

Luke Hohmann: The appropriate granularity is a function of the number of people working on the software and the complexity of the software itself. If only two or three people are working on the project, then they can get pretty granular. As the software and team gets bigger in size, the granularity must become more abstract. What's a subsystem when only you and I are programming? We'll have an architecture, but what's a subsystem? On the other hand, if you have 300 people building the next embedded missile guidance control system, you need to design subsystems, because each subsystem will have a group of eight or ten people programming it.

When people talk about architecture, there's rarely a corresponding discussion of the granularity of the architectural metaphors, components, or descriptions that are being employed. How do I derive practical advice if I'm in a project of 6 people, 12 people, 50 people, or 100 people? I don't necessarily claim that I have the answer to that. I just know that granularity is an issue we're struggling with. I think that one reason reusable components have not always taken off as we expected is because most people get the granularity of the components wrong.

Bill Venners: How does the number of people working on the project change the granularity?

Luke Hohmann: If you're a developer on a three person team all of whom are working in the same office, you're going to inevitably have an Agile or XP-style arrangement, whether or not it's an XP shop. The granularity in that architecture will be very fine. Three people can only write so much code, and each person will only need to discuss the architecture with two other people, so you'll talk about your architecture in terms of function calls and interfaces. If you're part of a 100-person team, however, you'll have an architecture with a hierarchical structure. You'll need to be able to talk about the architecture in more abstract terms.

Bill Venners: It sounds to me like you're saying that the architecture needs to facilitate communication among the team members. If 100 developers are working on a project, the code will comprise a much vaster ocean of functionality that the developers need to talk about and think about. Therefore, the architecture will need to have subsystems—larger concepts that have a name and can be discussed at a more abstract level. You can't just talk at the granularity of classes, because there might be a million classes in that project.

Luke Hohmann: Right. One of the exercises I like to do as a consultant is to give everyone on the project a blank, 8.5x11 piece of paper and ask them to draw their architecture. I find that the members of a cohesive team will each draw a similar architecture, and the members of a dysfunctional team will draw wildly different architectures. When a client asks me for something that I know will improve the quality of work done by the team, I say, "Make sure that everyone can draw the architecture." That's different than saying, "Make sure everyone has a picture of the architecture on their desk." The team members need to be able to generate that picture from what they know in their head, and the picture they generate must be very consistent with what everyone else on the team generates. The internally generated aspect of this is the key: every individual writes code based on the context of the structure that they hold inside their head, their own concept of the architecture. If this differs you're going to have problems. In social science terms, you want to reduce ambiguity (so that things are undersood one way) and reduce equivocality (so that you're confident in the meaning that you share).

Next Week

Come back Monday, April 5 for the next installment of this conversation with Luke Hohmann. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Luke Hohmann is author of Beyond Software Architecture: Creating and Sustaining Winning Solutions, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0201775948/

Luke Hohmann is the author of Journey of the Software Professional: The Sociology of Software Development, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0132366134/

The Pragmatic Programmer's home page:
http://www.pragmaticprogrammer.com/

A good place to start looking into Extreme Programming is:
http://www.xprogramming.com/

Talk back!

Have an opinion? Readers have already posted 5 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.