The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

Becoming an Architect
A Conversation with Luke Hohmann, Part IV
by Bill Venners
April 5, 2004

<<  Page 3 of 3


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, please subscribe to the Artima Newsletter.

Talk Back!

Have an opinion about the design principles presented in this article? Discuss this article in the Articles Forum topic, Becoming an Architect.


Luke Hohmann is author of Beyond Software Architecture: Creating and Sustaining Winning Solutions, which is available on at:

Luke Hohmann is the author of Journey of the Software Professional: The Sociology of Software Development, which is available on at:

The Pragmatic Programmer's home page:

A good place to start looking into Extreme Programming is:

Frederick P. Brooks classic book, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), is is available on at:

<<  Page 3 of 3

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use