October 29, 2009

Know the Domain (Shame on Me)

I write software that's tailored to solve problems for a particular domain, yet I don't know a lot about this domain. This lack of knowledge used to not really bother me, but now I find it very troubling. How can I be trying to solve problems when I don't truly, deeply understand the problems that need to be solved? It's pathetic and completely unacceptable. I need to know the domain for which I write software.

My previous performance reviews had objectives for learning about the industry that we write software for, and I've actually taken some steps to learn more. However, I've always treated this information as helpful and nice-to-have but not necessarily critical - and that's where I've been wrong. Domain knowledge is essential to creating powerful and wildly successful software, as it leads to a strong conceptual model and language that everyone on the team (not just developers) can use, as well as software that closely corresponds to this model and language. So I should be exerting as much effort towards learning about the problem domain as I have been towards learning new technologies, patterns, and practices.

What does the industry actually entail? What challenges is it facing and will be facing? Who are our customers? What problems do they have? What do they like about our software? What do they hate? How do they actually use our software (as opposed to how we think they use it)? What new features would they like to see? What's the roadmap and long-term vision for our software? I need to learn the answers to these questions and many more if I intend to design and implement innovative solutions for our customers. And as a test to determine whether I actually know the problem domain, I should be able to talk directly to our customers or potential customers using language that they understand, as well as explain how our software solves the problems they face.

Thus I'm trying to gain a deep understanding of the problem domain, and I'm curious to hear the ways in which I can learn more about the industry we're writing software for.


  1. Way back in the day, there was a big effort to increase the domain knowledge for the folks at your company (let's call it Wells2). In 2002 or so, a bunch of folks at Wells2 got together and wrote up as much about the domain as they knew. It was great, and they actually produced a bunch of content. It was on the intranet there, and I can't recall the name of it. Had a college theme to it. Maybe you can track that down.

    Another issue at Wells2 is that they've for the most part been telling clients what they need for a long time. Your users aren't crying out with a great idea of what they need, or even with a great understanding of what their problem is. What Wells2 has been great at is solving unknown problems with software no one has even thought of yet.

    Also, don't forget that one benefit of Wells2 is that you work down the hall from lots of your clients. Those are the folks that in most cases are using the software more than the actual firms that purchased it. I'd think of ways to tap them for info.


  2. I agree with everything Jim says. It's interesting that I might know someone who worked at Wells2 in 2002, and I don't think they were aware of that initiative. Or maybe they were at the time, but have since forgotten.

    Having lunch (or breakfast or dinner) with those people down the hall and with the people who set the roadmap and long-term vision is probably a good place to start.

    Actually working with the end user, while probably very interesting, is a bit more difficult. I can almost imagine being able to find a customer and say, "Hey, I'm a developer on that product you use and I'd like to understand more about how you use it, what problems it solves for you, and what other problems you have that it could or should solve. Can I just sit with you for a day and observe?" And I can almost imagine the customer saying yes. The trick is that in order to do that on your own time, you'd need to take a vacation day, which I suppose if I think about it, might be acceptable. I guess it's similar to taking vacation to go to technical training, which I'm sure we've all done.

  3. Jim & Amy -

    I wasn't aware of this effort to gather domain knowledge but think it's really cool. I'll have to try running this info down.

    You're absolutely right that Wells2 has been great at recognizing problems that no one realized or hadn't been able to really crystallize and then developing innovative solutions to these problems. I had an interesting conversation with another coworker about some similar topics, and he argued that listening to customers shouldn't drive product development because customers really don't know what they want. While I think this is a bit extreme, I do agree that the best insights and most innovative solutions come not from the customers, but from within the company. Customers may drive some new features, but the really innovative features are envisioned by the company. However, this innovation requires insight into the customers and the industry, which is what I really want to gain. And I want others to have this domain knowledge too, as a company can't rely on a just a handful of
    individuals to drive innovation. A company should instead develop a culture that values
    innovation and can thus benefit from ideas and insights from all of its employees.

    I would definitely love to visit a customer or at least talk to one. As for using a vacation day for it, I guess I'd be okay with that considering I'm willing to take a day to go to technical training. Yet I still feel that direct, unfiltered feedback on actual customer usage and perception would be immensely useful, and getting only a single day of it is not enough (and I'm certainly not using all of my vacations days to visit customers). That's why it would be great to find a way to incorporate stuff like this into our process in general, so that everyone can incrementally acquire more domain knowledge.

    And yeah, talking to the biggest users of our products - Wells2 Services - as well as the people responsible for the long-term vision of our products is a great first step. Now to make the time and then convince some of them to talk to me...

  4. "How can I learn more about the industry we're writing software for?" is a different question than "How can I convince my employer that software developers having domain knowledge will lead to more innovative products, and that the increased money made selling those products will cover the cost of the developers learning the domain?"

    Even though I think you're right—that spreading domain knowledge around the company is a good idea—I don't have an answer for the second question, and I'm not sure Eric Evans does either.

    Then there's your coworker's opinion that "listening to customers shouldn't drive product development because customers really don't know what they want." IMO, he's right in some ways. If your customer is telling you what feature he needs, or exactly how the software should work, he might be wrong, because he's not necessarily a software expert. Ideally, you and the customer work together to explore the problem, finding his pain points—because the customer is the expert in what's causing him pain. Then, you can work together on defining the problem and how to solve it with software.

    I'm sure there are several resources about how to do this, but the one I have read and can recommend is Customer-Centric Product Definition by Sheila Mello, which I think is in your library.