Cyrille Martraire
Transcript (Translated)
So the book club is a bunch of people who meet and share a book, read a chapter per week, and we discuss it. And over the course of the discussions, one week, we talked with the business experts, the interviewees, and at one point, a colleague had a surprise. What? Do you mean that talking with business experts is a skill? Is it something that can be worked on? Is it something that can be learned?
This surprise is the starting point of this talk. And so, right after the break, the commercial break, you're going to discover how to get better at grabbing, at capturing the business knowledge from your business experts.
So the commercial break, who am I? Cyril, a developer for quite some time now, Cyril on Twitter. And I'm fairly well known in Paris for having created the Paris Software Craftsmanship community, which meets every month. With communities of professionals who want to be better at their code and work better, work in test-driven development, etc. And better specify, better work with the business as well. I'm also a co-founder of the company Arola, where we're all fans of all things DD. TDD, BDD, Domain-Driven Design, so the latter. And we're going to talk a bit about that one today.
Alright, so back from the commercial break. Congratulations, in your job, you're going to work with business experts. And now, you feel... Yeah, well, yeah, okay, I have to go. Why is it so difficult to work with business experts? So, I asked the question at different conferences, and I was told, we don't all speak the same language. True, that's right. And also the other answer that always comes up is they don't have time for us. So it turns out that apparently, the more expertise you have in something, the less time you have.
You've seen that too. And so, the time of business experts, the better they are, the more, yes, the better OL players are, the less time they have for you. Which means that every time we spend time with them, we must be careful not to waste their time at all. And that starts with not going to see them unprepared. You have to go, and we're not going to waste their time, we're going to do our homework first, and we're going to learn a little about the business ourselves as much as we can, so we don't start from scratch. And to do that, I have a little secret, my friends, it starts with curiosity.
But sincere curiosity, be careful, it's not just superficial curiosity. Without genuine curiosity for the actual business, it won't work.
So curiosity, that's the first secret ingredient. That means if you're in finance, you're really going to be interested in learning a bit about finance. Actually, it's really interesting, by the way. If you're in insurance, you're going to learn a bit. Distribution too. Then, the thing is, my brain is limited. I need a bit of time to learn. And so, I'll start by doing my homework, as I was saying earlier, and I'll start by looking at everything that's accessible today to learn. So, there are lots of books, reference books, lots of things, we'll look at them quickly. In every field, there's at least one official bible of that field. It's easy to know, you take anyone around you, you ask them what it's called. and you get the Bible of your field. The other trick is that there are tons of XML dialects that have existed for a long time, which cost a lot to standardize and reach consensus on, like Oasis for example, etc. And those are goldmines of information for quickly scanning a field. What's it about? For example, in any field, there are hundreds of them. Do you want to talk about elections? You take a look at the Election Market Language. And you immediately have the important concepts that appear in that field. Emergency systems, crisis management, you have tons of stuff on that too. So don't take it as is, just look at all the names that appear in it. So be careful, this is very useful. It's very useful for getting an overview of your field. For having checklists of possible questions to ask, for having a corpus of vocabulary or candidate vocabulary, However, these are definitely not ready-made solutions to copy-paste. Definitely not. It's not a feature list either, and it's definitely not the truth. Your case is different. It's just inspiration. With all this overview, you immerse yourself in the field, and then you go see, hey, business expert, first of all, I'd like to know how an insurance policy works. And there, I use a precise business term.
And then the answer is, OK, it starts with blah blah blah, and there we start talking seriously, since we're getting to the heart of the matter, and you interest your interlocutors. Win.
So that's one point, I questioned, I interviewed several well-known thought leaders, big names in software development, those who created Agile, those who signed the Agile Manifesto for example, and repeatedly they confirm to me that it's something we never talk about. To succeed in their projects, every time, they are genuinely curious about their field, they really get into it. It's not just the tech, it's the tech and the business. But we don't talk about that often because we all have different fields, so it's not something that reaches consensus in conferences. Every time, if I take an example from finance, I'll lose everyone who's not in finance. That's a bit of a problem in our profession. So the other point is that my brain, still, has limited capacity. I need to write to remember. And so, it follows that the way of taking notes is super important. And so, I'm going to develop a technique for taking notes like a pro. Imagine I'm listening to a business expert in finance who tells me, 'The visitor requests an insurance quote.'
And I take notes, naively, like that. Do you see the problem? Ah! That's not at all what he said. We've already lost information. We've already lost opportunities to learn more things. What was really said is that it's not a user, it's a visitor. He wasn't asking, he was requesting. And it wasn't just a quote, it was... An insurance quote. Do you see how much we've already distorted the whole message? We've already lost all the vocabulary. So an extremely important point, and it's at the heart of Domain-Driven Design, is to pay very, very, very close attention to language and to respect the language. That means when we listen to words, we don't just grab the general meaning, we pay attention to which precise word, and not a near-synonym, which precise word was said, and that's the one we'll try to note. And believe me, in fact, it's much harder than it seems. Test yourself tomorrow. Compare your notes, memorize, compare with your auditory memory and you'll see, 'Oh, oh, oh, oh, oh, I didn't write what was said.'
It requires active listening. Active listening is something that can be worked on. In fact, it's something I also discovered at Agile France with a great presentation by Florent Chabanoy, who talked a lot about it. A few years ago. So it's hard, but you can turn it into a game. That way, it's a hit, it's more fun, which I call the Demo Safari.
Every time you hear a new word, you underline it. When you hear a sentence like that, you don’t need to understand what it says. I give examples about finance, but you don’t need to understand finance to grasp the message I’m trying to convey. Deal. Oh, a new word, I underline it. And then, at the next opportunity I have to speak, when I’m given the floor, could you define deal? What’s the deal?
And that’s how we learn things. So we continue the discussion, and thus the trade is booked in a certain portfolio. So I take notes.
And then I think to myself, but trade and deal, to me, are the same thing.
They’re synonyms.
And that’s an important point to notice. All synonyms are important signals for questions that help dig deeper. So, I’ll do this with questions like, you talk about deal and trade as if they were the same thing—are they really the same, or is there a difference? Is there a difference? That’s a key question. Every time I put a little key here, it means it’s a key question. It’s amazing, it’s a little trick.
A little code. And so, with this kind of question, we start digging, we really get into it quickly, we’ll dig very fast. Vocabulary is super important. It’s the gateway, the key to deeply exploring the profession. At this point, you might tell me, but all this is just tricks, little tips. Well, no, it’s extremely important.
It’s so important that Domain-Driven Design talks about it a lot, and it’s so important that Eric Evans, the creator of Domain-Driven Design, named his company Domain Language. Language is the foundation of everything we do here, and in the code, we’ll find this language, of course. We want to find this language. Okay, let’s continue a little. So we still have sentences like that, after execution, I’ll reduce the quantity of what remains by what has already been executed, etc. Oh, a new word!
And then I’ll respond on top of that. You’re talking about... Orders and execution.
I already know that an order is like an intention to trade, but what’s execution? So what I want to show you here is that I’ll start my sentence with ‘I already know that.’ And what do I do? Why do I do that? What’s the point of this trick? It’s to show interest, demonstrate curiosity, and build credibility for myself. When you’re facing a business expert who masters their field, whether you’re a developer or part of the development team in general, you’re not always very credible when it comes to understanding the business. Anyway, you’re just techs. I didn’t understand anything about that stuff. So, I take advantage of any signs of credibility I can create to position myself as a valid interlocutor for them. The goal is for them to grant me more time in the future. It’s an investment, creating a constructive relationship in both directions.
A bit of equality. Of course, we won’t be at their level, but we do everything to establish our credibility. And so, I have several ways to do this. Showing my curiosity, highlighting it, improving my questions as I learn, and then challenging.
Challenging means I won’t take everything at face value. I’ll dare. Ask questions that can highlight apparent contradictions in what I’m given, in what I’m told. All this with respect, but certainly not like ‘yes, yes, you’re always right, I listen to you and take everything as gospel.’
So, at this point, we’re having our conversations, etc. And as we’ve mentioned from the start, talking with people is difficult.
Fortunately, there’s an antidote. The antidote is that conversations are interactive.
What does interactive mean? It means you have control, for at least half of what’s happening. It means you can take the wheel and steer the conversation where it suits you, where you think there’s something interesting to explore.
I’m stumbling a lot for the camera.
Of course, we won’t interrupt the conversation abruptly. It means we’ll have to save our questions for later. And that’s where taking notes like a pro becomes essential again. So we’ve already seen that for all new words, I underline them—my little personal notation. You can have your own, but I have other signs, a kind of personal shorthand. Something that’s not clear—this thing here needs to be clarified later because this particular word, anyway, isn’t clear. And then all my own remarks, I put them in brackets to clearly differentiate them, showing it was my thought and not something that was given as truth or approved by my interlocutor. And of course, all the questions that come to mind too. Question to ask soon. Which means that at the next opportunity, I’ll glance over them and select what interests me as the next question. Others have more advanced techniques. For example, in the professional testing community—and I also invite you to check out their work—James Bach and Katrina Clokie, experts in professional agile testing, they have effective mind-mapping techniques that allow you to quickly explore different facets of a profession, with the goal of testing it, but it’s just as useful for the purpose of discovery and specification. In fact, it’s exactly the same thing, the same activity.
And so, by navigating your notes, no matter the form—text, mind map—you scan and then say, the most important thing for me right now, I prioritize my questions. The next most important question is this one. And so, we’re navigating the conversation. Like we navigate a map, doing this.
So imagine a rather pretty map—well, mine are rarely that pretty—but among all my note-taking mess, I have different concepts appearing. Here we have invoices, invoices printed in PDF and electronic invoices. And then there’s the follow-up for invoices, and then the concept of partner, invoices with partners.
We see several directions on this map. There’s top to bottom, bottom to top, and left to right. Let’s start vertically. Here, vertically, I have a semantic, an intention representation. The higher I go, the more I move toward the why of things. And the why, you know well, is a key question. I’m not teaching you anything new here. You already know this by heart, and even the five whys. But to illustrate it anyway, a little anecdote: imagine someone tells you, ‘I need a button for a...’ You ask why? Your interlocutor says, ‘I’ll check with the users.’ That’s already a sign that you probably don’t have a real product owner, by the way. You don’t have a real business expert, but rather a proxy role, since they have to verify elsewhere. Then this person comes back and tells us, ‘It’s because they need to send this printout to the next department.’ Is that a good answer? Of course not. Another why. Why?
They're coming back. Ah, because they need to enter the info into the route system. Wow! What the fuck?
We can do better than that!
Of course, we'll do integration instead. We're going to completely change, reconsider the need. So we can save time in this kind of approach by asking right from the start, from the first meeting, what's the goal? That way, we'll save time. However, if we're already deep into a process that's already in place, we'll have to work backward, that is, try, with questions of why and all sorts of tricks, to rediscover, to reverse engineer the real why.
Of the solution that was given to you as supposedly being a need. It's always like that, they give you solutions, but it's your job. You must not stop criticizing everyone; that's how it works. We have to accept that they give us solutions, they ask us for solutions, and we must find the real problem from these solutions. That's the job of the development team. So always, ask questions. And so, I don't know if you see here, it says 'Question everything.' And what I find great is the response from the little vandal who added 'Why?'
Obviously, if we go too far with this approach, we risk getting remarks like that.
That's true. It's true, we can get lost in the whys just to procrastinate and enjoy playing the intellectual, trying to understand everything, everything down to the universe. Well, we shouldn't overdo it either. But it's still a powerful question. There you go, in the other direction, I'll look for something concrete. And you know as well as I do that when we do Agile, we need user stories, we need concrete scenarios, and we'll implement based on concrete examples, especially if we're doing TDD and BDD. The key phrase for something concrete is an example in English. An example would be handy right about now. Those are Brian Marick's examples. Again, it's Brian Marick, a tester who signed the Agile Manifesto and who used to hand out his stickers. He always had some on the table. And regularly, in conversations, he'd pull out his card and say, 'I need a concrete example, guys.'
So, in real life, when we're in a company, we're more delicate. And a gentle way to put it, a key question, is, 'Okay, I think we agree, we're all on the same page, we've talked throughout the meeting, we agree,' but just to be 100% sure, ultra-sure, just in case there's still a little issue hidden somewhere, couldn't we have a concrete example anyway?
Here, you recognize the discipline of BDD, Behavior Driven Development, which consists of doing just that, seeking concrete examples, because we know very well that the devil is in the details, and it's in these concrete examples that we'll find all the problems. And in fact, even though we all agree, of course we don't, when we look into the details, we'll find lots of sources of dissatisfaction.
You know this, you've seen it before.
So obviously, BDD fits well with this, and in addition, there's all the proper formalism, but that's optional. Generally, when we have concrete examples, we can structure them like this; you put them later in Cucumber or Specflow, but that's secondary. The real benefit is having concrete examples on which to find and identify that ultimately we don't agree. All this allows us to discover the known unknowns and the unknown unknowns, the unknowns we don't even imagine, that we don't know about.
misunderstanding as early as possible, which means we progress faster and save time.
What I observe daily, in all environments, is that asking for concrete examples is difficult. Every time, they'll tell you, 'Yeah, but it's too slow, we don't have time.' It's faster to stay at the level of formulas, generalities, properties. I want the system to print a report when we reach the end of the day. Going as far as saying what time the end of the day is, how the PDF is structured, etc. That seems like a waste of time. It seems like unimportant details. But do we really save time if in fact we misunderstood and will have to correct it later, go back, do rework, reopen tickets? That really doesn't go faster. Next, when you ask for examples of documents, that's super useful. Every time there's a contract somewhere, a PDF, and there are quite a few, or an XML sent to a partner, ask for concrete examples of these documents and look at them yourself. Of course, it's often difficult for a human to parse; it's legal language, but you read it, etc. And there, you discover a term. What's this thing?
Oh right, we haven't talked about that yet.
Oh yeah, okay.
Super important. And again, I regularly see that we aren't given these. And we insist, we insist, we insist. There are confidentiality issues, of course. Often names, you have real names, real parties. In the past, I was lucky, that after insisting a lot, we were given some with big black bars over them, or just on paper, they don't give them to you but show them to you on a table,
but it's really worth looking at them, and that's why you need a bit of business knowledge, even a slightly deeper business knowledge, because to even get an idea of what it's about and to look a bit into the details, If you really don't know anything about the business, it will truly be useless. If you know a little about the business, you'll be able to discover that there's a forgotten concept in all this, or a misunderstood concept.
In parentheses, this gives you free test cases, this kind of document. It's ready to transform into your preferred formalisms for your BDD tools.
Finally, there's one more direction, the side approach.
And concretely, in a conversation, you're talking about a certain thing, you're talking about a shopping cart, blah blah blah, blah blah blah, and by the way, that's not the case on the marketplace. You take notes. Marketplace.
We were talking about building an order system with a shopping cart, but the marketplace, what's that thing? It's just a passing remark, and the risk is to let it pass. But it turns out that when we dig deeper, we'll discover that in fact, the shopping cart project was just the visible part, but actually, we'll also have to consider the entire marketplace, and that's the biggest part.
Oops!
Okay, so far, I've been a bit full of it, because until now, we've talked extremely positively. That is, Cyril, you don't really have the same life as us. You have business experts who seem great. That's not what you have. It's true that in real life, there's this phenomenon of the ideal business expert.
And it's true that you imagine that, but in fact, you have this instead, as a business expert. Moreover, it's impossible to recognize them; frankly, it's not written on them, 'I'm a good business expert' or 'I'm a bad business expert.'
And besides, business experts, even in their field, aren't all great.
Some still make mistakes.
However, there are still a few little tricks. For example, the worst business experts, that's discovered quite quickly, are those whose so-called business expertise is only expertise in the historical systems they've spent several years on. In fact, it's an application expertise they have, not a business expertise. So that's the biggest risk you have, making a mistake with a pseudo-business expert who knows the application that has always been by heart, and you'll never make progress because the future will always be described in the same terms and the same way of thinking as the old application that has always been like that. That's the absolute poison.
Conversely, to recognize a credible business expert,
it's someone who has lived, and who has even lived in their own flesh, having lost money, for example.
I made a mistake one year. Oh dear, how much did we lose because of that? I still remember. We have nightmares. Well, it can work in a positive way too. We made a great decision and it made a lot of money. So it's true that I hang out in finance too much, so these are a bit extreme examples, but it's really about having things, you need to have war stories. Someone who has really lived their thing, and so it could be a banker who used to be, who was a trader before, who was a quant before, who has a background in the business itself. That's an excellent example; in fact, those are the best examples I know, that kind of example. Or a CEO or a manager who has a background in the business itself.
But when we don't have that, or even when we do, but especially when your interlocutor isn't that good, we can help. And that's something normal. It's something normal. I mean, it's not just a workaround.
I think it's really our job to say, it's normal that I have to help my business expert interlocutor better tell me what I need to learn. And so obviously, this skill is the famous empathy. But what does empathy mean? It means putting yourself in the other's place, putting yourself in the other person's shoes, putting yourself in the other's in what they feel. But generally, when we think of that, putting ourselves in the other's place, we think of it figuratively. I put myself in their place just in terms of emotion. What I suggest is to go one step further and do it even literally.
Above all, we're not going to put ourselves in the business expert's posture, 'explain everything I need to know to me.' No, not that, especially not. What we want is a two-way partnership. You remember 'Challenger Respectfully,' I wrote, we're going to try to have an equal-to-equal relationship, or especially not a superior and subordinate relationship, And so we'll try to propose things too, we'll try to have conversations where I propose as much as I'm proposed to. I don't know if you know this guy, some of you certainly do, it's Ward Cunningham who invented the wiki, CRC cards, and with Ken Beck, extreme programming. And who is still working on Federated Wiki, and other things too. They really did... And the patterns too, yes, I forgot. Well, it's nothing much in our line of work, really. So this gentleman, who is extremely interesting, with little remaining, had written a long time ago,
This great meme, I love it, this great phrase. The best way to ask a question on the Internet is to have the answer. It's not about asking the question, it's about posting a false answer. And then, you let the Internet correct you.
So it works really well on the Internet.
It also works really well in conversations. Suggest something, suggest anything, as a tactic. So, in fact, an order, if I understood correctly, is a way of... That's what you receive when you've sold something. That's not it at all. Suggest something, but still do your best, because your credibility is at stake here, though it's not a big deal. Just do your best, and it's absolutely not a problem if you're off the mark, if it's wrong or incomplete. Because a subject-matter expert, whoever they are, will be happy to correct you.
That's brilliant. Precisely, we'll use everyone's natural tendency to highlight what they know better than you to liven up the exchange a bit.
That works really well.
I'm not the only one saying this, actually. If you know Lyskeo, she also talks about it regularly in her articles. So, for example, let's say, given that I start all the work, and you let the other person finish, ultimately. You lead your interlocutor to complete the sentence. Ah yes, so in this case, delivery is free. And all you have to do is turn that into an example, take notes, and you have the complete thing.
There you go, so it's not automatic, and it's not that easy. So when we have all these conversations, we do them in conversation sessions that can be half an hour a day, an hour a week, two hours a week, sometimes less. But when it works well, a certain regularity is needed. It's still nice, though. But when it's over, the interview is finished for today. And so now, if we're lucky, we'll see each other again tomorrow.
And now, what are we going to do?
The development team will work. We'll take what we've understood and put it into code. Don't be afraid, we're at Incamban, but I'll show three lines of code. So imagine that your business is the business of little singing kittens.
I'm sure that exists somewhere, in Japan for example, that must exist. Little singing kittens. So what is this business about? We can see it in the image. It's about microphones, it's about headphones, it's about a rockstar attitude. For each of these concepts, we'll find them literally in the code, in the form of a class, method, interface, enum.
The classic code artifacts. So you have a kitten with a microphone, and they sing into the mic. And then there's also the notion of playback. There aren't just nouns, there are also verbs, actions, things that happen. And of course, the rockstar attitude. And that's code. So this is code that we read like text. But taking notes in code means it's code that runs, that executes when you launch it. You should have text that displays, or if you connect it to a speech synthesis system, you should have 'meow meow meow' when you run this code. It has to do something, it has to behave. And that's where the code will help you specify. Let's say it's like a notepad, it's disposable code, let's say it's disposable. But it's code that will help you understand. And it will become an extension.
Once you take your ideas, even very rough ones, it's very useful in an initial POC, for example, you put these initial ideas into a small piece of code, you run your code, and oops, it doesn't do what I expected. So what's missing? Ah yeah, a concept is missing. Imagine, for example, that you're coding a protection system. I have a concrete example with credit default swaps. It's a bit like insurance. You play with it and say there's a default, so the insurance must intervene.
But then, you continue to pay the subscription, to pay for the protection. And the credit swap doesn't work like that. You think, but why does it continue? Ah yeah, I forgot the termination criterion. A concept is missing. The very next day, I go back to the subject-matter expert and tell them there's something missing, there's a termination criterion, we can talk about it a bit more. It was the code that showed me the solution. You can also do it manually, you can play it out manually, execute your understanding manually, but it's tedious and in fact, you won't do it. With code, it's much better. And so the code and the problems you encounter while trying to make it work, even on a very small scale, we're talking about simple small models, will generate questions that will allow you to ask better questions next time, and thus gain credibility points, and start a virtuous cycle of conversation and collaboration. Of course, talking, interviewing subject-matter experts, is a cycle where most of the time, you're not with the subject-matter expert, of course.
So the idea is to be effective here to... to have interesting work afterward. For example, on a POC, half an hour a day here, the rest of the day there, that's great. All of this, every day. That would be ideal. If we could really do that, have so much access to subject-matter experts, when we can have so many experts at our disposal, that's really the best.
And since my brain is always limited, I need time to let all this mature, we won't go too fast, we'll take a couple of weeks, for example, on the POC, and then we'll continue even after when we really develop something deliverable. And over time, we iterate on all this and gain depth and relevance in understanding. It's a phenomenon that Eric Evans calls the 'knowledge crunching spiral' in Domain-Driven Design.
So why bother with all this, actually? It's true, after all, we could just code and see what happens afterward. And why not? If your language is very fast to work with, I encourage you to do it. If your language is more complicated, if you have legacy systems, if you have other problems, It's still worth discovering very early, even before going too far in the code, all the problems. Because the complexity is there, no matter what. The complexity of the business is hidden behind. You don't see it.
And if it will come back anyway, you can ignore it, but it will come back to bite you one day or another. So the goal of all this... is to discover it earlier, to find the scale that will allow you to see what's behind, to save time and avoid rework. Of course, there will still be some rework, but we'll try to minimize it a bit, if all this isn't expensive.
In parentheses, here, the scale wasn't the best idea, because you can also go around it. Of course. Well, and all that, we win. So at this point, now I'm going to make you work a little.
You are all business experts in something. And you are all necessarily business experts in something called pants. You have all worn pants for years.
No, no one. You all know what pants are, don't you?
So, we'll give ourselves three minutes, maybe even less, maybe even two. Two minutes, and I'm going to ask you, since you're pants industry experts, And I'm going to ask you, in pairs, in small groups, to give a very clear definition of what pants are. What are pants? A definition. You know what pants are. You should be able to give a definition of pants, shouldn't you? And I'm starting the timer. So, I won't ask you to present it back. So, don't be afraid. Go ahead. But still, have your definition in mind. Here we go for two minutes.
Is it easy?
This is where we'll make millions.
Ah.
Aren't you doing anything over there? Okay, is it done?
7, 6, 5,
There we go. So, how was it? Was it easy?
It was... You're not so smart now, are you? Was it easy? Not so much. What's actually happening? You don't know what pants are? Actually, I think what's happening is that you're really in the role of a subject-matter expert, right here, right now, on pants. It's something you really know. The problem is that this knowledge is... Tacit.
You know it. However, to explain it, to express it, to put it into words, is really more difficult. But you know it, you know everything. And so this difficulty is a classic difficulty for subject-matter experts: I know, but I can't explain it. It's unconscious. Sometimes, it's so internalized that I don't even know why I think that way. And on the other hand, extracting all that, formalizing it, these are things the development team knows how to do; it's their job, we're professionals at this.
One of the ways to help bring this out is also to challenge, to do thought experiments. For example, what would happen if I changed something? And that way, we'll generate new examples. So this seems very abstract. Let's look at this right now. Let's try some new examples. Would your definition of pants allow you to answer this question?
You probably didn't see this debate on the Internet, on Twitter, a few months ago. Does your definition of pants allow you to answer this question?
No? Yes?
Are there any? Does it work a little? Well, there were debates, debates, debates, debates, debates. What's the right answer? And then one day, at some point, someone found the answer. There was a girl, she answered, but you're all idiots. Actually, obviously, it's to cover the buttocks.
The problem is that... Oh no, find a counterexample.
So, either we keep this example and it doesn't work, or we say that this example is actually a bad example and it does work. But even if it really was to cover the buttocks, we'll correct our little question. And now, does your definition allow you to answer this question, after having corrected this issue about covering the buttocks?
Is there one for which the definition covers and answers this? Yes, a little.
And would it also allow you to answer this?
So, there's another... Yes, because they don't have buttocks, actually. Then, actually, there was another guy who had found the answer too. You're also idiots, actually. Of course, it's to cover the legs. Of course. Were there any who had this answer? Yes, still.
Well then, if we don't have legs either, does it work? No, it doesn't work.
And besides, if it really was to cover the legs, would it allow you to answer this problem here?
With millipedes.
Does your definition allow you to settle this kind of debate? What are legs? What are legs for an animal with N number of legs? This is the kind of situation we often have, like, how many situations. And so ultimately, here, we've only postponed the definition problem to the definition of legs. The definition of pants now needs a definition of leg, and we're not out of the woods yet, actually. But what I want to highlight with this silly example is that the power of a definition is its ability to work in different cases. And the more cases it handles, the more powerful your definition is. Of course, if it comes at the cost of a complicated definition, it might not necessarily be a good idea. It's up to you to balance it. And you replace 'definition' here with 'modeling.'
And you're directly in terms of design, in the territory of design, because specifying is already modeling, it's already taking a stance on a worldview that will end up in your software.
And in parentheses, I don't have the solution here.
So, Cyril, do you have other techniques? Secret or not secret? Actually, yes, there are plenty. I even had to cut a lot to fit it into this talk.
So, guys... And one of the obvious techniques, of course, is to keep your mental toolbox to yourself as well. And my mental toolbox starts with good books. So, there's a very good book here, of course, Domain-Driven Design by Eric Evans. But in fact, what isn't talked about much is that there was also Martin Fowler's book, which came before, and it was already a Domain-Driven Design book. It's a book on analysis patterns. That is, Martin Fowler realized, while working in the healthcare system and then in accounting, that there are actually tons of parallels between all these professions, and we find the same situations, small bits of situations, that repeat almost everywhere. And these small bits of situations, if we work on them well, once we've found smart solutions for one, We can reuse them for others. That's the whole idea of patterns. But here, we're not talking about code patterns. We're talking about patterns, of course, they also show us how to implement them in code. But we're talking about patterns like managing the temporality of things, things that are valid between two dates, then become different between two other dates. And all the ways to represent or think about that. How to manage systems where we only add information and then consolidate later. Measurements, observations, phenomena, quantities, all that. So that's an important investment. And in fact, this kind of mental tool, in your mental toolbox, is extremely powerful. Because afterward, in a conversation, you say, this thing really reminds me of that pattern. And then you dig a little to check right away if it fits or not. And if it fits, you've framed the problem. You already have an off-the-shelf understanding that comes from your mental toolbox. The mental toolbox also contains math. Of course, I'm a big fan of monoids. And so, I'm definitely not going to talk about monoids with my interlocutor. I'm not going to scare them like that, after all. You don't need to know what a monoid is. But I'll give you an example right away. I'm going to try to test if I have a monoid in front of me. I have hotel reservations. And I have one from the 26th to the 27th and another from the 27th to the 28th, could I say that if for the same client I have two, then could I say that it's equivalent to having just one from the 26th to the 29th?
Maybe yes, maybe no. If it's yes, then I have the behavior of a conceptual arithmetic. Mathematically, I would have what's called a monoid, but you don't need to talk about monoids. To detect that. So of course, past experiences, the more past experiences you have, the more you recognize small situations that you can recognize and reuse directly. This is again something that ISKEO also describes in its articles, like accounting patterns that are found in places that have nothing to do with accounting,
An example you certainly know is the concentration of powers. Almost all professions dislike the idea that one person can become a complete dictator. And we will separate important powers so that there are always at least two people sharing all the powers. And so, once you've understood that, you've understood it in a certain profession, you arrive in another and you discover. You're a bit surprised. I still expected there to be a segregation of duties, of powers here. It doesn't seem to be the case. You suggest it, it's also a way to gain. Precisely, in a conversation, you score points when you bring that up, because generally, it will be true. Yes, it was a mistake. It wasn't planned for everyone to have all the powers to do things that cost money, spend money, put the company at risk.
Another example you've probably noticed is that most businesses dislike erasing information destructively. We erase logically, we don't erase physically. And so if you're asked to erase, and Aspect talks about erasing, don't hesitate to challenge that too. Did we really want to erase? Oh no, no, no, in fact, of course. We'll do it in an accounting way, we add an entry that replaces the previous one. So these are examples from your toolbox, reusing your toolbox to converge faster and propose and participate more actively in conversations. With all this, we have faster discoveries. And one last tip is all about invariants. And here, the key question, the magic question, is given by ISKEO: could there be another outcome that would be important? Could there be another result, another behavior that would be important? I have another way of saying it too, for example, with an example, because we're always on concrete examples to be precise, And so, I'll say, the budget is the sum of all the tickets. For example, the conference budget, of course, according to what we said, is the sum of all the tickets, right? of all the tickets.
Okay, yes.
And then I bring out my secret question, my magic question. Could there be a case where this wouldn't be true?
Power Cushion.
Yes, in fact, it's true that there are still people who don't pay, for example, the speakers. And then, there are also people who give, who give more. There are donors, there are people who... And then, we also have sponsors. Oh yes, so in fact, it was false. So, we win. Now, our formula... We had understood well for the tickets, but we had missed the donations, those who don't pay, and the sponsors. Aha! We progress with this kind of question.
So in fact, if you do domain design, you necessarily have context bandits somewhere. And so, in this context, generally, if you have several domain experts, it's a frequent case, generally what you have is this.
Several domain experts mean confusion. But we can also look at it in a positive way. The confusion may also simply mean that they are perhaps discussing the same business in general, but each is looking at a particular facet, under a particular sub-domain, and that this will give us clues to illustrate that in fact, there may not be just one way to see your business, but that there are two very different ones. For example, the way of selling will generally be very different from the way of buying. or the way of covering risks, if only because you have completely different objectives. Where the salesperson wants to get rich and have their bonus, the finance department just wants the company not to sink and will do everything to ensure that all clients are solvent. So they have antagonistic objectives. That will contradict each other at certain times, they won't have the same vision of a client at all. For one, a client is someone who will say yes and sign. For the other, it's a balance sheet, solvency, etc. It's normal that they don't have the same description of the same thing, the same client in flesh and blood. That's the concept of a context bandit. Completely, in all its splendor. I won't elaborate, we don't have time and it's not the subject today. But I'd be happy to talk about it in the questions afterward.
I won't talk to you about it.
So, a small bonus tip today.
We have conversations and we talk with words, but there's not just words.
There's also all the...
A concrete example from a long time ago. Should we, in a stock system, have order books and buy and sell orders, they are sorted. How do we sort them? Should we sort by date or by price first?
And here, the answer is... I would rather say by date. Ok, so I’m taking note, sorted by date. Comment to myself. Not convincing at all.
What does that mean? That means that... I’m already going to assume right away that a change of opinion is likely, very likely. And I’m going to include this information right away in my design. And in terms of code, I’ll already plan a place where I can easily substitute the comparison criterion with another, at no cost. With no particular cost, so using a pattern like the strategy pattern, for example, and a small comparator, or a function that you inject, if you can inject functions in your language. Of course, when we do this, we’re speculating.
That is, we’re introducing design that isn’t absolutely necessary right now, in a proven way. However, We still have clear information, which is the uncertainty, the fact that we’re really not sure. And this information, I claim, is still a good reason here to protect ourselves with a very slight design overhead. What’s amusing here is that we’re still going to transform hesitation directly into informing a design decision. I love that. But I think it’s really important to include the full picture. After all, if we feel emotions and uncertainty, it’s not for nothing. It must be useful for something, somewhere.
Now, logistics. Don’t neglect logistics. An extremely brilliant trick a colleague once showed me was to walk around everywhere with a small envelope, a small binder, with printouts of all the important screens.
Yes, they were a bit like that, by the way, for many of them.
Screens like that too. And all sorts of... All the screens we regularly talk about in the... In meetings or in conversations.
And the important benefit is that when you discuss, you’ll save a lot of time and gain precision by pointing with your finger and saying, I’m talking about this. I think it's really important to include the entirety of the image. After all, if we feel the emotions and the uncertainty, it's not for nothing; it must be useful for something somewhere.
Finally, logistics. Don't neglect logistics. An extremely brilliant tip a colleague once showed me was to walk around everywhere with a small envelope, a small binder, with printouts of all the important screens.
Yes, they were like that, by the way, for many of them.
Screens like that too. And all sorts of... All the screens we regularly talk about in meetings or conversations.
And the key benefit is that when you discuss, you'll save a lot of time and gain a lot of precision by pointing with your finger and saying, 'I'm talking about this.'
Suddenly, it becomes much more concrete. Haven't you noticed that often in meeting rooms, it's all empty, and you're talking into the air, hoping the other person has the same image in their head as you, when all you'd need to do is bring the image? And so, even low-cost methods are still very effective. If you have screens, they're everywhere now, but it's not necessarily a good idea because finding your image—first you log in, half the meeting is already over, and then finding the right place in your document manager with a specific format, no, no. Nothing beats a few printed things in a small folder that you keep with you. It's much faster.
Next, another logistical point: the location.
What's the difference between this place and that one? Do you really think meetings will go the same way in these two different places? If you've ever tried to have a meeting here because there was no space there, You've certainly noticed the difference in atmosphere. Already, when you're here, you feel less like you're being watched, you can speak more freely, let out what you want to say. Isn't it true that we always design meeting rooms like this in companies?
This is a photo from the internet, not from a client.
This place is magical too. This place is magical.
Because up until now, there's also an unspoken assumption that we're supposed to have scheduled time with business experts.
In reality, we don't often manage to schedule regular meetings and things. However, if you hang around here, you'll still run into them from time to time, regularly, more and more often. And it's actually here that you might be able to truly move your project forward.
So don't underestimate it—spending time here is work. If you really want your project to move forward, it's work. Then, of course, the smoke break too for those who smoke—it's an unfair advantage for smokers. Another logistical tip: if you're not many, if you all sit on the same side of the table, Then you can draw together without having the drawing upside down. It seems silly, but it's still super useful.
It's an example, and it allows you to use all the specific languages of all the professions. And all professions have specific languages. If you're in finance, we draw cash flows over time like this. Positive, received, or negative. Of course, music has its language, mechanics has its language, supply chain management has its graphical notations, and even satellite launch missions have their own notations for doing this. And of course, even dance has notations. In fact, if you dig a little into your profession, there are multiple notations for warehouse management, there are notations in almost everything. And the more mature your profession is, the more mature the notation. So language is also notations, sketching, the whiteboard, and all the little diagrams we can make with them and point to. And it's better if we're on the same side of the table.
We're reaching the conclusion. And in conclusion, buy my book.
Well, that's not the real conclusion. In the real conclusion, but it's still a real book.
And it will be available from Addison Wesley in print next year.
Everything I mentioned today is just examples. The important thing is that you personalize your toolbox, your own, based on your experience, what works well, etc. However, I must warn you about a few clichés that are a bit annoying. The first is... It's the role of the worker, the developer-worker. Tell me what to do, and I'll do it. A problem. No problem, I'll do it perfectly. No, that's bad. We're not in a constructive relationship at all. So it's the pure executor. The other extreme, still among the typical pitfalls of developers, by the way, is 'I'm an architect, I'll impress you with my brilliance, my technical excellence, I'll do things.'
I know some. I know plenty.
Then there's the third problem, which is more like mine, for example: 'I'm smarter than you guys, and I understand your job better than you do, so I'll explain it to you.' That's dangerous on many levels, even if it's true, by the way. It's still very dangerous. And so I propose this golden rule, which is to always, always, always make them feel Make it very, very clear that I'm not putting them at risk. Always speak under their control. I have no intention of taking their job. And it's something I have to provide reassurances about regularly, give guarantees of all that. Ask for confirmation on everything. And most often, it's that systematically, you have the final say, always. And I always give you the opportunity to have the final say. Always, always, always.
Which effectively means we have conversations as equals, but in the end, it's you who validates and has the final say on everything.
So, I hope with all this I've convinced you that just these conversations with business experts aren't as trivial as they seem; it's something that requires work. It's a thing.
So to conclude, and still just maybe debunk a few myths, Of course, I also choose projects based on their potential, particularly their potential to have a rich domain to explore, a rich business domain, and one that's rather differentiating, where software can do something interesting. That's also why I've liked finance for a long time, in parentheses. And the other point is that I also choose projects based on the ability to access people. Now, it's not always as planned, but it's still an important point. So I have a bias. You don't necessarily have the same bias. But with all that in mind, in the end, I like these words from...
Proposing ideas isn't just a tactic; it's also a way to increasingly suggest innovative ideas, real novelties, real business value propositions. You saw earlier, we saw earlier with business models, that when a good model has even predictive power. You can take a model designed for two legs, and it can sometimes predict that it would also work on eight legs or N legs. These are things we can extrapolate. You take your understanding and extrapolate it, and it suggests things. We could also do this, we could also do that. And ultimately, we reach the holy grail of this collaboration, which is when we end up proposing things from both sides based on the code. The code suggests new features. And there, we reach a point where we move from just supporting a business to augmenting a business, doing things that weren't possible before software. And so, we're in a new phase of value creation. This is something that isn't possible as long as we're separated, as long as those who know what to do and those who know how to do it are separated.
That's essentially what Michael Fedor said in that article.
And so we must stop with this dichotomy of business versus IT versus business.
This separation has been going on for a long time. It prevents seizing opportunities like software blended with the business that enables augmented capabilities.
So in practice, generally, we can't do it. Today's companies still don't accept this well. Ideally, we would rebuild the teams, stop the separation, no longer have an IT department and a business department, but rebuild both together. Right now, we don't have that. But we can still do it on a small scale, even if it's pretend, but it's still almost like the real thing, with exercises like event storming, where we put everyone in a room, During that day, everyone will be one, there will be no more separation, no silos, we will all be together.
Another way to do it, my image is quite messy here, is the mob programming mode, where everyone is in the same room, so the entire development team, and there you have your business expert who is invited and comes for the duration of their task. If we work on something for two hours, we will try to have them for those two hours, the time we work on the user story they proposed. And so here, Mob Programming talks about the Product Owner, but if we replace Product Owner with Domain Expert, we have the best of both worlds for the success of your projects. It's 6 PM, thank you for your attention, and have a good weekend! Oh no, not yet! Oh no!