In the Programming and Development blog, Justin James asks, "Should programmers know more than just programming?" The majority of respondents chose this possible answer to his poll question, "Yes, they should know more about the business and technical side of things." In the discussion, a few members countered that you need specialization in order to get the most out of each individual.
My take is that, the more you know about every aspect of the business, the more effective you are — regardless of whether you're a developer, an accountant, a secretary, or a CEO. Yes, you need to specialize and obtain a deep understanding of your craft; but if nobody knows what everyone else is doing, the business will come apart at the seams. And developers in particular need to understand all of the related processes within the business that they're attempting to automate.
That's fine for full-time employees who can make time in their busy schedules to learn more about the company, but what about consultants? We might work for several companies in a month, and clients come and go. Furthermore, clients may not be willing to pay our exorbitant hourly fees to teach us about their businesses for very long. Still, understanding a client's business processes can contribute greatly to the quality of the solutions you provide.
How much domain knowledge is enough?
Well, it depends. If users will directly consume what you're working on, you need to know how they will use it. The more you can learn about that domain, the better your design will be. But I misspoke: Your creation will always be consumed by users — it's only a question of identifying who the user is. In use-case parlance, identify your stakeholders.
For many consultants, the users will be the client's IT department and/or office workers. Most of my clients are software developers, and the type of work I do for them is usually not specific to the applications they're creating (e.g., how do you create this general kind of user interface? or how do you get A to talk to B? or can you use a utility class that does X?). So, for me, the user is a programmer/designer. The application in which they'll use my contribution can also be seen as a user. And occasionally, the specific use cases of the application require that I understand part of the end-user layer as well.
How broadly do you need to understand each layer?
Again, it depends. Separation of concerns is a good practice in programming but also in business processes. How well your client can do that will be inversely related to how involved you'll need to get in order to understand everything you need to know. In other words, even though the business is better off when everyone knows something about what everyone else is doing, it's far worse when everyone needs to know what everyone else is doing. When that's the case, one shaky domino can knock everything down. You'll have to understand all of those interactions, effectively becoming yet another edge in the huge web of dependencies.
But you don't necessarily have to accept the situation; you're within your rights to suggest ways in which concerns can be separated and interfaces simplified and documented within both code and business operations. The latter requires a pretty thorough understanding of the situation, so how can you quickly gain that knowledge?
One technique I like to use is to envision how I think the business works, assuming the processes are well-designed and then ask confirmatory questions. "I presume that you do X, which leads to Y. Is that right?" The client's answer is usually, "Well... not quite." Then I know that we're onto something.
But their explanation is often so complicated that my eyes roll up in my head. When you get an answer that you don't understand, it's generally not a good idea to gloss over it in the expectation that you'll figure it out later; those are almost always the key points that need addressing. As the saying goes, if you can't explain it to Grandma, it's not a good model. So, if your clients can't explain it to you, don't feel stupid — either their model really sucks, or they're smoke screening.
You don't necessarily have to redesign their whole business, though; your goal is to sufficiently isolate the processes that you need to understand in order to provide your services. If you can get to the point where, for example, you produce a specific document in a rigorously standardized grammar, and you ship it off to some other service, you don't want to need to know what that service will do with the information. Nor should you need to know how the department that owns that service operates, presuming the business concerns are likewise separated.
Your mileage may vary; mine has from client to client. How well your client fosters communication and separates concerns within their business can dramatically affect how quickly you can contribute meaningfully. What are your experiences?Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.