Collaborating with Domain Experts

[00:00:00]
>> Mike North: In this next part of the course, we're going to focus on solving the problem of a disorganized collection of seeds and get back into the mode of domain modeling and interviewing a domain expert or collaborating with a domain expert or an LLM to figure out, like, what is the most productive direction we could go for solving this problem for our user.

[00:00:23]
Before we get into this, though, let's talk a little bit about some tips for having conversations with domain experts, and then we're gonna have a conversation. First, it's very important to develop a shared vocabulary with all of the people you're collaborating on discussing a problem space with. What this helps.

[00:00:46]
What this makes sure that is avoided is things that end up being lost in translation. And you want to make sure that you have an opportunity or you give less technical people an opportunity to correct misconceptions you have. So if you're talking to your gardener about your plans to help organize their seed catalog and you say, well, what we can do here is we can take these objects and we can put them into an elasticsearch collection and we'll have different dimensions that we can use to search.

[00:01:26]
Put some denormalized data into elasticsearch, you've already lost them. It's not that difficult to take the names of classes and the names of variables and tie them to this common language that you share with your subject matter experts. When you're working with agentic coding tools, this also helps make sure that that you're encoding more of the business problem right into the source code of your app.

[00:01:56]
So you can have conversations that are much more in line with like, tell me about this seed packet, do we have an estimated weight for the seed packet? And it's going to be able to go and find some terminology that joins the words used in the problem space with the words that are used in the solution to the problem.

[00:02:20]
So, tips for having discussions that are conducive towards developing a shared language. You want to understand terminology that's being used, ask clarifying questions, make sure you really pin these things down, and take the time as these words are mentioned for the first time or the second time, coming up with a nice glossary of what do we mean when we say this is very well worth it.

[00:02:49]
Use visual tools like this little diagram tool that I've been using, which is called Whimsical. You could use a whiteboard, you could use a notebook, whatever you wanna use. Slides are great for diagrams. This helps make visual concepts more tangible and try to avoid technical logic and sorry, technical terminology such as referring to database indices or instances of classes like, you want to see if you can articulate the shape of how you're thinking about the problem in solution agnostic terms.

[00:03:25]
Tip number two, stay curious and open. There's a failure mode for these conversations which well intentioned people that want to collaborate can fall into. If you're talking to a gardener and you listen to them say a few things and then immediately you propose, you're like, here's how I think we could solve it.

[00:03:47]
And then you sort of blurt something out. What's going to happen is the gardener is going to listen to this and they will pattern match against it and they'll assume like you're a software engineer, you're probably pretty smart. The words you're saying mostly make sense to me. But sometimes you get into this trap where they'll kind of accept that description of a solution at a point in the conversation where you haven't reached alignment, where you haven't gotten to the point where you can both say, yes, the way we're thinking about this is the same and we've actually explored all of the details in this case.

[00:04:23]
All right, I can give you a list of your seed packets and you can use command F and you can find basil. Great. I guess I can find all of the basils I can advance. If I have Thai basil and sweet Genovese basil and all of this, I guess I could control F and all right, that's fine, but what if there's incremental data loading and everything's not on the same page or something like that.

[00:04:51]
You've offered a solution where sometimes people accept it without knowing that there will be inherent limitations to what they're validated to. So tips for avoiding falling in this trap, focus on the business problems. But what we mean here is like focus on the problem space, the business here is doing something useful for a gardener.

[00:05:15]
Ask open-ended questions, right? You wanna understand the why behind the ask, like what? What is the core pain that is experienced which the solution is aiming to develop? It's like aiming to mitigate that pain or take that pain away entirely. Document and respect nuances, right, sometimes edge cases and corner cases turn out to be really important.

[00:05:43]
And while there is a point when you're implementing a minimum viable solution, you can start to say, all right, we know we will eventually need to do this, but for now let's not worry about it. An example of this would be, well, we've got this carnation plant in Our database.

[00:06:04]
And we want to represent that you can affect the color of a carnation based on the factors of the soil. So if you say, I want a blue carnation or red carnation, that's not necessarily about planting the right seed. That's about additives in the soil. And so, all right, but let's worry about that when we come to it.

[00:06:27]
Like, for the most part, we at least need to capture this dimension of, like, there are different species of plants. Let's worry about that first. Soil additives can come later. It'll layer on, but it's important to not lose track of it. Request concrete examples for complex scenarios. And what I mean by this is have your domain expert walk through what they do in the absence of your solution, step by step.

[00:06:54]
So if, for example, this is an accountant trying to perform some calculation, like literally get on a whiteboard or get in a doc with them and say, take me through, like, step by step, you start with this number. Then what happens? Then what happens? Okay, you consult this spreadsheet, who makes that spreadsheet, and just walk through that process that can become what is called a user journey.

[00:07:21]
That is the user journey of today. The process your user goes through to get from the beginning of having the problem to scratching their own itch, if there is a way to scratch that itch today. And that lets you avoid missing things, that lets you make sure you at least understand the world of today and especially complex scenarios as you hear about these nuances, dig into them, understand them, and then obviously show active interest.

[00:07:51]
Sometimes you'll be dealing with a dry subject, dry topic. Some people get really excited about. Well, I'll say I get really excited about financial concepts, which is great. I work at Stripe, it fits really well, I'm genuinely excited when I go to work to sort of wrap my heads around different business models and things like that.

[00:08:12]
Other people would consider that to be incredibly dry. But you do want to make sure that you're trying to tease out these details in a way where you're sort of feeding energy into the conversation. And remember, presumably you all are excited about building software, and ultimately that's part of this.

[00:08:30]
And so try to tap into that enthusiasm, iterate and validate regularly. A key part of domain driven design that I think is definitely worth keeping is the idea of refining knowledge. I know we all have probably in our careers dealt with. Somebody puts a big document together and they say, this is the plan.

[00:08:53]
And then as you start working on the plan, it changes course and that document is like no one's updating it. It's just sort of rot. It's important to sort of take a look at the information you have as you make progress on implementing things and thinking through things.

[00:09:12]
And sometimes you have to write some code in order to figure out like, well, I have a set of new questions now. Refine that knowledge, go back and keep a nice concise source of truth that you're willing to keep up to date as you iterate. This could be just like a one page document with your glossary of terms or a simple diagram like this where we changed temperature range, we combine that into a single monthly temperature range entity.

[00:09:41]
Instead of having that intermediate value object here, have something you're willing to keep up to date, and that is usually not a 30 page design doc. A big tip here is summarize and reflect concepts back to experts. This is easier than ever with LLMs. If you have taken a ton of notes, you can feed it into something like chatgpt and say give me the most important bullet points here.

[00:10:12]
Focus is important. At the ends of these conversations there's an important step to take and that is like you'll have a bunch of notes and I want you to sort of like if you have a half hour discussion with someone, what you want to do is save the last three or four minutes to with your collaborators ask the question, what, if anything, we've discussed is worth keeping and carrying forward?

[00:10:38]
It's likely not all of it. You've gone into some avenues where it didn't yield anything. Or you have a very elaborate carnation related topic here that could really be boiled down to for now we're focused on plant species, although other variations of plants will exist. Maybe that's all you need to do.

[00:11:00]
And that's the important gem to mind in the org of the full conversation that you had.