A Conversation with Luke Hohmann, Part IV

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 Part III: Human-Oriented Architecture, Hohmann discusses mapping software architecture to human needs, choosing languages for social reasons, and selecting the appropriate architectural granularity.
• In this fourth installment, Hohmann discusses the social role of software architects, the value of sticking with a product release after release, and the importance of domain knowledge.

The Social Role of Software Architects

Bill Venners: What's the role of a software architect?

Luke Hohmann: Most people think of architecture as technical, and the architect as a technical person. And absolutely, the architect must be technical. But there's also a social aspect of the architect role that I think is not well communicated or understood. The architect is the person who will say, "This is the way we do things."

An architecture is like a dirt road. The first time a car drives over it, the road looks about the same. By the time the 10,000th car drives over it, though, there will be grooves in the road. As an architecture mature, it gets grooves.

For example, one kind of groove that is common in architecture is error handling strategy. Whether you handle errors by returning error codes or throwing exceptions is part of your architecture. In practice, most teams will choose one error handling mechanism as the dominant approach, the other as the subordinate approach, because you often need to use both. Among the roles of the architect is choosing the dominant approach to error handling, keeping the flame of the dominant approach, and educating the team on when the subordinate approach is an acceptable alternative. That's one aspect of the architect's job, and that's a social role.

Conversely, you can tell when a system hasn't had an architect, because it lacks consistency in things like error handling, naming, and so on. In a system I'm working on right now, for example, I noticed that some of the database tables have a unique identifier column named id, other tables have a unique identifier column named <table name>id, and other tables do something completely different. So table foo would have a fooid column, and table bar would have an id column. I finally went to the development team and said, "Let me guess. You've had more than one DBA [Database Administrator] in your time here." And they said, "Oh yeah, we've had five of them." Every DBA had their own way of naming columns. They didn't have an architect to ensure a technical consistency in column naming. There wasn't a notion of conceptual integrity from a technical perspective.

Bill Venners: What do you mean by conceptual integrity?

Luke Hohmann: That goes back to Frederick P. Brooks in his book, The Mythical Man Month. Conceptual integrity means that one or few minds are making the decisions, and the rest of the people associated with the project honor the decisions that were made. I may have an opinion on how to name table identifiers, but it's not like I would really care whether they chose to give every table a column named <table name>id or one named id, because at least there would be regularity. The current approach requires you to have the schema in front of you, because unless you magically remember which table does which thing, you've got to look it up. That little bit of friction is an example of a technical architect not being involved. So the technical architect is a person who helps make sure the big picture decisions are made, and then keeps them consistent throughout the team.

Sticking with a Product Release after Release

Bill Venners: In your book Beyond Software Architecture, you write, "You're not an architect after your very first job. You're not an architect after the first release. There is simply no substitute for sticking with a problem long enough to receive and process the feedback generated through customer use of your system." What kinds of lessons can be learned through actually seeing the results of your decisions at a much later time that you wouldn't learn otherwise?

Luke Hohmann: Let's compare two candidates whom we are considering hiring for one open position. The first person says, "Hi Luke, here's my resume. I was the architect for this system. I did it, and then I moved on. Then I did this system, and I moved on. I did this other system, and I moved on." That person has the advantage of seeing different problems. I'll give them that. It's not one year of experience five times, it's five different kinds of experiences. But let's compare that to the other person, who says. "Hey look, I did this system through three releases, and I did this system through two releases, and then I did this system through four releases." I can have a qualitatively different conversation with that second person. I can ask, "What did you learn about the first system that informed your choices for the second?" What did the first person learn about the consequences of their decision that helped them make a better choice for the next system? Nothing, because they weren't around.

Humans are failure machines. We're not success machines. We're failure machines. We fail all the time. And it's only through processing the feedback of our failure that we learn how to correct for them and do better. That is why it is important to stick with the choices you make and understand how well they worked. Is it better to give each table a column named <table name>id or id? Which is better? A person who sticks with a product as the database schema migrates and changes over time will be able to give you an answer.

The Importance of Domain Knowledge

Bill Venners: In your book, Beyond Software Architecture, you write, "The requirement of domain knowledge for a [technical architect] is so strong, that few developers can be promoted to this position until they have considerable experience and skill building systems in the specified domain." Why is domain knowledge important? Why isn't good general knowledge about software development sufficient?

Luke Hohmann: In the field of cognitive psychology, there is a tremendous amount of literature that says that domain knowledge trumps technical knowledge in many endeavors, including software. Almost invariably, the ability to make correct decisions about the handling of a given issue in a given domain is based not on technical skills, but on domain skills. I discuss this extensively in my first book, Journey of the Software Professional.

Bill Venners: Can you give an example of the importance of domain knowledge in software?

Luke Hohmann: I am working right now with a company that provides analysis tools for engine performance, and driver performance of the engine, because engine performance is partly correlated to how the driver drives it. One of the issues is idle time. If you can lower your idle time, you lower your costs. One of the requirements of our software, therefore, was to measure the idle time of the engine.

I didn't know how to measure idle time, so I floated an idea to the development team of how we should do it. Other developers came up with some alternative approaches, and we compared these to what a customer had provided. We eventually settled on one, but, before implementing it, we took it to a major customer to see what they thought.

I learned that my approach was wrong, as were the other ideas floated by the development team. It took a customer -- an expert in the domain, to tell us "This is how you measure idle time," and, "This is why you measure idle time this way, because this is the behavior that we want to be able to control."

For example, should the software measure idle time at a stop light? The developers said, "No, you should have a threshold below which you throw away idle time, because the driver can't control idle time at a stop light." And the domain experts in the industry said, "Actually no, you never want to throw any data away. What you want to do is capture all the idle time. As a developer were expecting us to be able to drive idle time to zero. We don't. We expect idle time to have different values based on the terrain and the climate. We don't expect idle time to ever be zero." I like to think of myself as a fairly good developer. I'm strong on the technical side. In this domain I'm weak on the domain side. In this situation, strong technical skills would have implemented a completely wrong domain solution. Thank goodness we triple-checked with a committed customer.

Bill Venners: This is another way in which the right way to design something depends on the situation, in this case, the domain.

Luke Hohmann: Absolutely. Let's leave the business domain out of it, and just look at the technical side. The idioms and practices for programming embedded systems are extremely different than those of multi-terabyte data warehousing. If I'm processing payroll receipts for Safeway, it's pretty different than building BREW applications on a BREW phone, right? Independent of the domain that I'm servicing, the technical infrastructure of those two kinds of applications is very different. If you are an expert in one, are you by definition an expert in the other? No.

Bill Venners: So as a developer, how do you become knowledgeable in both a technical and a business domain? How do you decide where to focus?

Luke Hohmann: The trick is to have enough of a broad base of experience that you can pick the area of technology that you, by interest and skill, are suited to do. In other words, find something that you're reasonably good at that you also like as an interest. Become skillful in that area. If a team chooses C++, fine, but learn the bloody language. Learn how to use a copy constructor. Learn how to use an assignment operator. Learn the idioms that create high quality C++ code. Then focus on your domain skills. If you're in real estate, take a real estate class. If you're in graphic arts, learn how artists use pallets.

As a consultant, I do ask my clients, "What magazines do you read?" And then I'll read those magazines. I want to learn what they do. How often have you walked into a place and they're just zinging acronyms back and forth? And your sitting there thinking, "What the hell is a GRB?" Well that's part of what it means to be a domain expert: knowing what a GRB is.

The person who is an expert both technically and in the domain is a master in both dimensions. In your professional development, you want to zig-zag between them. You want to start with the technical foundation. It's why you take classes and learn the idioms of C++, or whatever technology you've chosen. It's why you learn how to program safely in C++. And then you start applying that technical knowledge to your domain. As you build experience in that domain, you start to settle in on areas that will be the focus of your career.

Next Week

Come back Monday, April 12 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/

Frederick P. Brooks classic book, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), is is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0201835959/

Talk back!

Have an opinion? Readers have already posted 1 comment 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.