Maxime Mader, Yannick Grenzinger

So this presentation is called Coding Fast and Slow. Who here is a developer? I know one.
That's great!
That's great, we don't have to change, we said damn, we presented this for... There are many people who don't develop, Aline Cambon, we made a mistake. I'll let Maxime introduce himself first.
It's quick.
To tell the truth, he does Microsoft. Well, at Devoxx, you're going to have a ball, there's no more technique, we don't care. So, I am also a Technical Officer, but on the Java side. I do a bit of everything, including JavaScript. And right now, I have a rather special job coaching software craftsmen at Société Générale, which is quite interesting. This presentation, in fact, for those who have already seen it, is the same as at Evox, so it's actually tailored for 45 minutes, which leaves some time, and I want to play a bit with the audience. If you have any questions, raise your hand and we'll talk about it.
A little bit of advertising, it will please our bosses. So Carbon IT is a company with two main pillars. We tried to define what the values were. Maybe not the values, we're not there yet. But at least, what were the pillars of the company? It's code and product. We don't have agile coaching. We'd like to do the X, but it's not yet. But it's really about developing and developing within the framework of products.
Come on, let's get started.
This presentation is in four parts.
A question?
Oh, I lied. I like to lie. So, it's in four parts. We're going to give you an introduction to the psychology of reasoning, because that's a bit the underlying subject of the session. And we'll try to apply it to three elements. The whole of estimation, it's reasoning with things you heard this morning. The construction of reality and the flow or psychic negentropy. The word really exists, you'll see.
So, we like it, we'll try to make this a bit dynamic. So, we made a quiz. So, imagine, it's a character, a person, a young woman named Linda.
She has a master's degree in philosophy and when she was a student, so about ten years ago, let's say, she was super active in everything related to discrimination and social justice. She even participated in anti-nuclear demonstrations. Now, I'm going to involve the audience. In your opinion, is she a receptionist and active in a feminist movement or is she simply a receptionist? Who answers A?
Who answers B, the rest, raise your hand anyway just in case.
Are you going to cheat or what? Are there people who know? So, another question, are there people who knew? No? I would be curious to know why you answered B. In fact, most people normally answer A. Why? Because they make a reasoning based on the text, on what the text leads you to, so she is active in everything related to social issues, etc. We say, most likely, she must still be active in it, she must be part of a feminist movement. But what we forget is to make a purely logical, purely probabilistic reasoning, saying that there are, let's say, 100,000 receptionists, and receptionists who are also active in a feminist movement, there are maybe 10,000, or even less, 5,000, 1,000, I don't know, I'm giving random numbers, but it's just... And this is part of what is called the law of inclusion. You have a huge set, you take a part of this set, even if it fits the text better, in probability, no, it's more likely to be just a receptionist. I'll let Maxime speak.
He's the one who will finish you off.
So first of all, what is reasoning? It is actually a cognitive process by which we will go step by step to reach a reasoning that can allow us to do several things, such as verifying a hypothesis, we can very well make a judgment, we can try to find new things. This process, in fact, will allow us to chain what we will call inferences, and it is this process of reflection that we can call reasoning. of reflection that we can call reasoning.
So, there are two main types of inferences. We will see the so-called induction inferences, where here, we start from a particular case, we try to deduce a general case. So how does this read? In fact, it is said that if A is true, and if B is true, then if A is true, we try to hypothesize that B is also true. In the context of deduction, we will rather start from a general case. We start from the principle that A is true, and we say that if A, to be more precise, is if A, then B is true, then B is also true. So these are two inferences that are symmetrical. So to illustrate this, because it will be a bit clearer, if we take the example of Newton's apple, we can start from a particular case, where we see a tree, we see an apple falling, we can say hey, there's an apple falling, we see that in fact all apples fall to the ground, from that we can deduce the general case, all apples fall to the ground, and subsequently try to see a concept that is increasingly broad until arriving at gravity. It doesn't always work. A nice example is, for example, swans. For a very long time, it was always believed that swans were white. Especially in Europe, until the day we went to Australia, we discovered that there were swans that were black. So in fact, we don't yet have a global vision, we don't have a hypothesis, we don't have the general case that is proven. But from observation, progressively, we will draw logic towards a truth that will be global. For an example of deduction, we will start from propositions that will be true. There is the famous phrase to illustrate deduction which is about Socrates, which is 'All men are mortal, Socrates is a man, so we can deduce that Socrates is mortal.' " And this reasoning, in this case, is always true in the logical sense. However, it requires that the prior conditions be true.
And if you want something even more twisted, check out abduction. It's very fun.
So, a little history on the psychology of reasoning.
A man who pushed the study, the first who conducted a real study on reasoning, is Jean Piaget.
He was born at the end of the 19th century and from 1920, he theorized the psychology of reasoning as being a rather constructivist approach. For him, nothing is innate, everything is constructed. And he saw the reasoning process, he saw it as intelligence, as an optimal evolution of the soul, quite simply. It is through this work on reasoning that we have come to strive towards a case of optimal intelligence.
So what did he do? It's actually interesting in ontogenesis, which is a word that means we will study an organism from its birth to its death. Well, in this case, he didn't kill little children, but he limited himself to the period from 0 to 16 years. For him, he actually divided the growth of the organism, that is, of a child, into 4 main stages. The first stage he calls sensorimotor, which is rather the period between 0 to 2 years, where in fact the baby will rather have sensory and motor experiences, he will learn to discover his world a bit and he is not yet at a stage of advanced reasoning in the logical sense. Then there is a preoperational phase between 2 and 6 years, where in fact there is the discovery of language, drawing, symbolism, and we have a reasoning that is very much a prisoner of intuition and spatial references. A simple example is, for instance, if we take a liquid, we take two glasses of different sizes, we put exactly the same amount of water, well if we have a glass shape where the water level
is higher, the child will have the impression that there is more water on one side. For example, if we put marbles, we put six marbles on one side all close together, we put six marbles very spaced out, he will have the impression that there are more marbles on the side where the marbles are spaced out. It's a good idea for your gifts.
I'm a young dad, so I exhale a lot.
So, actually, it's a good example. An example to see the limitations we have in terms of logic. A little later comes an operational stage, where we have greater mastery of spatial references and intuitions, we actually have the learning of numbers, the ability to classify, and we have a beginning
of concrete logic, but which does not yet allow us to reach a stage of abstraction. So, we actually remain on very concrete things. And much later, for there to be an ultimate stage, which is actually called the formal stage, where we actually come to understand that reality is a particular case of the possible. It's that we can formulate hypotheses and actually have deductions based on these hypotheses, and so we call this hypothetical-deductive reasoning. Note it down. So all of this is very nice. The problem with this is that it's very linear, it seems a bit too perfect, and in practice, we see that some children are quite advanced, while others are a bit behind. So when Piaget was criticized for... These observed discrepancies, he began to talk about horizontal décalage and that these different stages are divided into sub-stages. He later spoke of vertical décalage. In fact, he tried to ensure that the theory was always right, even though it was clear that it didn't work. Also, if we look at this theory, we might think that when we reach the last stage, we have the stage... We have a being of pure logic, and in practice, we see that this is not the case at all. We still make mistakes, and this at any age.
So, a few years later, around 1980, we have Evan, Skadman, and Turski who actually worked on, rather than working on pure logical reasoning, how we arrive at truths, they were more interested in reasoning errors. Before them, there were many studies, books on logical rules, on how to find good results, but never on errors. And so this is a first work by Evans who identified reasoning errors, began to catalog them, and experiment with them. Later, we have Kahneman and Tversky, who discovered what we call cognitive biases, which are somewhat like design patterns in development.
Bad design patterns.
Yes, bad design patterns, actually. In fact, these are mostly systematic errors that recur all the time. And so, there is a classification of these cognitive biases that mainly come from intuition.
And what Kahneman also observed is that he tested his students, who were very educated, very intelligent people, studying, for example, mathematics, statistics, and he saw that even so-called well-trained minds made... a lot of mistakes. And this, in fact, applies to both inductive and deductive inferences. Their observation is that, in the end, we make mistakes all the time.
So, to give you a little idea of the categories of cognitive biases, because if you look, for example, on Wikipedia, it's very interesting, I recommend you check it out later.
There are about 150, I think, or more than 100.
There are 120, 150. There are different categories. Some are sensorimotor, others are at the level of attention. Others relate to memory, others to systematic judgment errors, reasoning errors, and others linked to personality or culture. We will go into more detail later in the presentation.
What is super interesting is that you encounter these biases every day, some of which are extremely powerful. We will see that it is very difficult to avoid them. To go a little more into the details of what Daniel Kahneman did, this is where we shamelessly stole the title, we didn't copy it, we outright stole it. And for information, he is someone who worked precisely on these reasoning errors and, based on his research, launched what is called behavioral economics. An economy that is not entirely linked to the invisible hand of the market and people's ability to be entirely rational, but rather based on the irrationality of people's choices. He highlighted them. And in fact, he created... I'm stealing your 'in fact'.
He created a metaphor which is the fast and slow brain metaphor. As I say, it's a simple metaphor. I think everyone knows the right brain, left brain metaphor. At first, we actually thought that they were two parts with different functions, different things. No, in fact, the two brains have different processes, but are not linked to one being creative and the other logical. If you cut one, one won't be more creative or vice versa. The Fast and Slow metaphor is exactly the same. You don't have one part of the brain that does your quick reasoning and another that does the long reasoning. It's a whole, it's a metaphor for how it works. To explain the metaphor, for those who know, it will bring back memories. What is the metaphor? You have a fast brain, which is something whose action is non-conscious. You are going to do something and it won't be linked to deep reasoning, to reasoning you have controlled. Simply put, it's the example of you driving home one evening, a route you've taken for the ten-thousandth time or the ten-thousandth hour.
If someone asks you what happened, you won't even know. You might have passed, not a deer, but at least the 20th intersection you know by heart, and you won't have noticed it. And this is actually one of the problems related to traffic; accidents often happen within 20 km of home because we are so much in automatic mode that if an unexpected external event occurs, the brain won't even take it into account. To come back to a small example. Do you know the experiment with people passing a basketball? Who knows? pushing to a reasoning that you have controlled. Simply put, it's the example: you come home one evening by car, it's the route you've taken for the ten-thousandth time, or the ten-thousandth hour, if someone asks you what happened, you won't even know, you might have passed, maybe not a deer, but at least the twentieth intersection that you know by heart, you won't have noticed it. And by the way, this is one of the problems related to traffic; accidents often happen within 20 km of home because we are so much in automatic mode that if an unexpected external event occurs, the brain won't even take it into account.
This is to return to a small example. Do you know the experiment with people passing a basketball? Who knows? Only one? Go watch it, you'll understand. Watch a short video of people passing a basketball; you especially need to count the number of passes made. And besides that, you have the LAN system, system 2, which is called LAN, maybe it's pejorative, so system 2, which is rather linked to reflection. You have a math problem, an algorithm problem, an architecture problem, you will have to think. If you do architecture using system 1, it can be very funny, but we will try to reflect. You have a problem of what the client's need is. If you do it using system 1, it will also be very troublesome. So we will try to activate system 2.
We will see later, one is not better than the other. When I present it, the first way I present it to you, I will tell you that system 1 is not great, it makes mistakes. System 2... It's great, you have to use it as much as possible. That's not entirely true.
I come back to the 10,000-hour theory. What is 10,000 hours? It's about turning system 2 into system 1. You train for 10,000 hours on the cello so that playing the violin on the hardest piece in the world becomes automatic. We do katas in computer science; those who are developers might know this. Katas are for making things automatic. There are many elements like that, and afterward, it will become easier and easier. We learn shortcuts in an IDE or Eclipse so that it becomes automatic, goes faster, and we code at the speed of light. And this is also the example of this... Of this person who drives Formula 1; if you put someone who hasn't learned, who hasn't gone through system 2 to 'I drive at 300 km/h on a circuit,' it's impossible. If the guy takes time to think about every turn, he won't drive at 300 km/h; he'll drive at 50 km/h.
The other thing is that system 2, you might say, let's put everything on system 2, let's try to think everything through well, control everything, except that in fact, it consumes a huge amount of energy in the primary sense of the term. If you only use system 2, in the end, you will run out of sugar, you will fall asleep in your chair, you will doze off, the act of taking a nap, etc., spending time doing something else. So to make the connection between the two, how can we differentiate them? It's that they each have their own importance. System 1 is more about impressions, intuitions, feelings. For information, there is a study on the... They show images in a quarter of a second. And the question that... may seem a bit odd, is whether this person is homosexual or not. And afterward, they try to say the same thing with other people, but by thinking better, by giving more context. And in the end, system 1, and this may seem counterintuitive, you will see, in psychology, there are many things that may seem counterintuitive, even strange regarding the ethical side of things, is that people who give an answer in a quarter of a second are better at determining whether the person is homosexual or not. It's sad.
And it's true, though after psychology studies, there may also be biases related to the studies; we could talk about that more later. And the other is related to beliefs. So you have used system 2, but it's very difficult to remove beliefs. Alright, to troll a bit, Hypernet is the best database management system in the world. ORMs, you should always use an ORM; it makes using a database easier. Is this a belief? It's also related to self-control, meaning favoring system 2 over system 1 requires self-control. Which is not always accessible to everyone all the time, but especially what consumes energy. Constant self-control consumes energy. Unless it's part of your system. There are people who work on this.
I'll ask another quiz, a bit harder, because the first one, at first glance, was too easy for you. So it's a card game, you have, it's a card game, yeah, it's queen and king, 7 and 5. The idea is to turn over the minimum number of cards, so I'll try to find some volunteers, to verify the statement if a card has... On one side, it has a 5 on the other side.
Who's going to try?
Alright, we'll start here, we'll go to the back. Go ahead.
One card? Quite brave. Which one? Okay. In the back, just the Q? Alright, two more answers for fun.
The Q and the 5?
The Q and the 5. Alright, we'll stop there; it was the Q and the 5. Well, that's good, we got you there. It wasn't the Q and the 5; I'll explain. Actually, the 5 is a mistake. In fact, the idea is to check if a card has a Q on one side, we are trying to find out if it has a 5 on the other side. We are not trying to find out if we have a 5 on a card, then we have a Q on the other side. And the classic mistake in system 1, meaning if you don't think, which is also logic tests, if you don't think, is that you'll say, oh yeah, the 5, because in fact, we are led by the statement. In fact, it wasn't just the Q; it was the Q and the 7. To check if the... To explain quickly, if behind the 7 there is a Q, the statement is no longer valid. Is no longer valid or logical.
I'll finish explaining. In fact, for those who answered Q and 5, especially 5, it's mainly the 5 that's the mistake, the Q is quite simple, but the 5 is harder; it's that you fall into two biases. The first is the confirmation bias. trying to confirm our intuition. We have an intuition, we will do everything to confirm it. So we say, okay, we roughly read that, we have a 5. And then, you will see, biases also chain together, they build on each other. Second, you have a matching bias. In relation to what you read in the text, you will try to confirm what you read, confirm your intuition. You tell yourself, as soon as there's a 5, I'll go see what's there. Oh no. Did you want to add something? Well, it's going to be your turn. You're still going to add something.
So, a little later, after the release of 'Thinking, Fast and Slow,'
So, he continues to work, a Cadman, Evans, Tversky, until 2014, there are always new publications. In the early 90s, we actually have the next wave with Damasio and Oude, who themselves were interested precisely, if we have a system 1 and a system 2,
in which case system 1 will take over, and in which case system 2 will take over. Damasio himself said that what will make us choose between system 1 and system 2 will also be emotion. And he sees this actually, he enters into a concept of homeostasis, meaning he will take into account the emotional state, just like blood sugar, body temperature, as a state...
Stress too.
Stress.
Super important.
Which will influence the decision and the choice of whether I will use my System 1 or whether I will use my System 2 to answer a question or a problem.
And behind this, we have Oudé, who suggests asking the question, 'Isn’t there a system or something that allows us to inhibit, to prevent us from using System 1 or System 2, depending on the situation?' a system or something that allows us to inhibit, to prevent us from using System 1 or System 2, depending on the case? And for that, he thought, if emotions influence our decision, whether through somatic markers, perhaps we can use these emotions to bridge the gap, to be able to control this System 1 and System 2. So what Oudé will do is try to link these two theories to arrive at a new theory, and thus System 3, which would actually be a system whose purpose would be to perform this arbitration function. So the somewhat complicated term is this inhibitory control that provides emotional guidance. And how will he actually reconcile Piaget and Kahneman? Simply put, what revolutionized these studies in the 1990s and beyond? It was the arrival of digital imaging. That is, we were able to conduct experiments to observe that the areas activated when working in System 1 mode and System 2 mode were not the same, that by using emotions, by trying to encourage and train people not to make mistakes with this emotion of... I must not make a mistake at all; I will try to take my time before answering. We were able to see that the areas activated in the brain were actually the frontal areas. So to go a little further, it’s everything related to the neocortex. That’s outside my field. But the idea is, how can we revisit Piaget’s somewhat linear growth theory with the calming System 1 and System 2. It’s simply actually... With the growth of a child into adulthood, the frontal part of the brain is the one that develops the most slowly. And as a result, inhibitory control only comes later. What we were able to observe is that we had traces of this System 2, even in babies. who, following experiments, will focus mainly on graphic games where you can play with your child if you have one, because you can play with other people’s children. So we will...
Well done! Put that! I’m doing this, it’s good. So the egg games, of course, they do both.
For example, if you show an object to a child in one hand, you close it, then you open it, and they see there’s a new object. If you repeat this action several times, and at some point, you disrupt the experiment, if you finally hide the object, open your hand, and the child sees there’s nothing in it, they will be surprised, they won’t understand. Sometimes, they will take your hand and try to look for where the object went. And the idea is actually that... From these observations, they will be able to use what they have noticed to try to reassess what will happen in the future. And so this is actually Bayesian inference, which is a somewhat more complicated concept, where we will integrate the observed result into the antecedent in order to be able to update somewhere the algorithm that will tell us what will happen when the person opens their hand.
And that’s why we hate magicians.
So, last slide on the subject, then we’ll do a little less theory. To go further, we can look into the development of reasoning comprehension. How do we think?
The term will be metacognition, which is actually thinking about thinking. It’s how we can act on ourselves to avoid making classic mistakes, which we’ll see right away, by the way. It’s about trying to develop automatisms and logical rules, to develop what we will call neurocultural strategies to guide, to train ourselves to make the right decisions and judge,
to change the natural way we have of alternating between System 1 and System 2, to provoke, for example, when doing intellectual tasks, it’s very important to try to force System 2, and in our case, to force System 1 instead.
Is that good? Yeah, I’m going. So, what’s good when talking about biases, just a quick feedback bias, is that we thought we had time. So, in fact, we’re going over it. So, if you look, it’s an anchoring bias. We have time, and in the end, we’re really eating into it. So, maybe that’s it too. So, we won’t be as good as Vasco from RT this morning, but we’ll try to take it on, we’ll approach the subject a little differently. Well, differently, no, in the end, it could be similar. So of course, as you saw this morning, it’s that we ask people for estimates who roughly say to their System 1, well, it will take two days, oh yeah, okay, three days, well, XL, S, whatever we want. Sometimes there are discussions, but since these discussions quickly become emotional, we stay in System 1. And then we use them as deadlines. And what’s very funny is that if you’re very, very old school, it gives you this. A good Gantt chart. And it’s magnificent because this is a series of biases that, after 2-3 years, lead to an estimate of the time it will take, so we understand why everything fails.
Maxime will present some different strategies. It’s always fun to remember them, how we estimate.
So, I’ve had the chance to vary my professional experiences in rather startup environments, small companies, very large companies, medium-sized companies. As a result, in the different challenges we’ll have regarding the estimation problem, it’s simple. We’ll be asked how much time it takes to do this. So, when I started working professionally, I had already seen quite a few things, I told myself, I know what to do, I multiply by 7 the number I have in mind. So if I think of my 1 hour, I tell myself with all the time, all the times, they’ll bother me. I say 7 hours, and it worked roughly.
You can use Pi.
So what we can also do is... double the idea we have in mind. We can also tell ourselves, hey, if I have a manager who tends to try to reduce my estimates, I’ll rather say, I’ll give them double what I think, so I’ll keep some margin. In the end, we’ll actually arrive at this game, it’s just the price, we’ll really try to guess whether we’ll rather satisfy the manager when we give estimates, or give something at least tangible. What we also have is that, I can also take the example of my child, when I tell them things or when I do things and they don’t like it, what do they do? They spit out their pacifier, they’re not happy, and they run around. Managers sometimes do the same thing. It can be at different levels. It can simply be saying, 'No, that’s not possible.' or 'Do it differently.' 'Figure it out.' It can also be, 'My boss said we have a week, it has to fit.' 'Figure it out.' In the end, what we can also have is simply the Spanish Inquisition, where sometimes we can be told, well, you estimated it would take so much time, we did the project, it went over, explain yourself. And that’s just a good idea.
I love that one. We went a little further, we said, well, we need to stop messing around, we’re going to try to address the question, we’re going to try to do science around it. At least, pseudo-science. So this is an example of the Kokomo 2 formula, which is roughly the peak of pseudoscience I’ve found. We try to actually take into account, because the first model wasn’t complicated enough, it’s about trying to use the number of kilolines of code, the number of bugs we had on average per 1000 lines of code, that kind of thing. So we said, to be sure, we’ll take into account, well, there are magic constants but we shouldn’t pay too much attention.
And also, just to finish, as developers, they don’t extract magic constants, so we don’t even know what they mean. So remember.
We still reviewed while waiting to do the talk. I didn’t remember what those little constants were. Actually, it’s whether they’re factors based on the developer’s or manager’s experience. We’ll take the years of experience, put that with kilolines, and somewhere it will give us a date. It's not bad. So, the 80s passed, in the meantime time has gone by, more scientists have worked on it, and we've arrived at something much better. The budget is good for finding that. It costs a lot. If you go to work, for example, in industrial groups where they use the methods of the American Department of Defense, I worked in the DOD
2165B I think, where you have a whole bunch of documents to do, specification documents, test specifications, architecture documents, etc. They actually based themselves on that to justify large projects in cycle B. So they capitalize on each project from the failures they measure and they try to put all that into the... to try to limit the damage.
And yes, and so, when agility arrived, we still said to ourselves that it had become very complicated for not much benefit. So we returned to something much more, let's say, simplistic, in human terms, you know. Which works rather well. I have a question for the Assembly. Do people, well, I imagine, I hope you know, that's why, when you do planning poker, when you have to vote, everyone must hide the value and show it all at once. test specifications, architecture documents, etc. They actually based themselves on this to justify large projects in cycle B. So, they capitalize on each project based on the failures they measure and try to incorporate all of that into the Kokomo formula to try to limit the damage.
And yes, so when agility arrived, we still thought it had become very complicated, and for one, we didn't see much of it. So, we returned to something much more, let's say, simplistic, in human terms. Which works rather well. I have a question for the Assembly. Do people, well, I imagine, I hope you know, which is why, when we do planning poker, when we have to vote, everyone must hide the value and reveal it all at once.
Why?
Yes. And the term behind psychology is anchoring. That's what happens in negotiation. When you start negotiating your salary, ask for 70,000 euros. It will work better than if you just ask for 2,000 euros more than what you had. Does it work? I don't know.
Well, however, it still remains very human. It still remains based on system 1, on emotion. So, it may not be perfect. However, what we notice is that those who do things like 'clambant' (as in the game 'le furet'), it won't shock them. What we notice is that someone who was doing Scrum told me, we noticed that after a while, in fact, all the stories, let's say they were t-shirt sized, were medium. And in fact, what we see statistically is that you will always end up roughly around a regression to the mean. For information, regression to the mean is really a statistical element that occurs. If you have a series of random numbers, you quickly get a regression to the mean. This method is quite amusing.
And there's also another thing we notice, it's almost what we see in the Chaos Standish Group Report, which is that the bigger the project, the more the quality of the estimate spirals out of control. And the smaller the project, the cleaner it is. So, okay, isn't there a solution? Can't we put these two elements together? So, what would the solution be? First, it's about starting by doing only small things. So, if you didn't understand by the end of the two days of Incamban, you really need to redo it next year, I'm advertising. So, reducing slicing, we say in slightly more technical terms. So, we will slice each task into the smallest possible task. And when we've done that, what can we do? We can start measuring. We can do Kanban. I'm not a Kanban expert, but I learned two very funny things. There are two measures that are super interesting. It's the cycle time, how long it takes to complete the task. The developer spends on completing the task. And the lead time, how long it takes from discovering a need to having it in production. The client can use it. And from that, with regression to the mean, we can start, as Vasco from Arte said, it's that in fact, we do stories, we have 400 stories, it's roughly one day per story, so it will take about 400 days. And there you go, we can estimate, or rather not estimate, close to 400 days. Say 400 days. Of course, you need to have data, you need to use... In fact, what you need is to simply use an Excel file rather than human estimates. I even think that maybe the next solution to go further would be to use machine learning or something like that, and let the machine learn how long it takes to do things. That might be the next level up.
I'm going to address a topic that I really like, which is the construction of reality. Piaget already talked about constructivism, reality is not something fixed, a state of fact, but rather a human construction, well, a construction by each person. And one of the figures I love, whom I strongly recommend you read, is Paul Watzlawick, one of the founders of the Palo Alto school, which is a school of systemic psychology. And he worked a lot on communication and precisely the construction of reality. He also, since he talked about the construction of reality, discussed the way we dialogue and communicate. It's also linked to psychology, when there are tensions in a couple, in a family, what should we do? In fact, one of the big problems, if you've ever argued with someone and then made up by saying 'but we didn't understand each other,' is that two people can talk about the same subject and have a vision, and even if they agree with each other, they don't construct the same thing, and they speak differently. And in the end, when they truly understand each other, they say, 'well yes, we agreed, it's just that they didn't use the same terms, etc.' " So, in fact, Paul Watzlawick explains this very... Or the Palo Alto school explains this quite simply, they say there are two... There are two orders of reality. One of the first order, which is the one that is... Let's say sensorimotor? Motor? Well, we don't care. One that is linked to the senses, meaning we will see it, we will touch it, which is tangible. So if we talk about money, coins, everyone agrees, a coin is money. But on the other hand, in the second order, it can have different meanings. For an accountant or a project manager, it might be the Excel file and the budget. For a financier, it might be stocks, finance itself. And for someone who is anti-capitalist, it might be, we must overthrow money, money is evil, etc. Many meanings related to money. I have a question for you in the Assembly, though I only have developers, it's not fun, but I'll ask the question anyway, what is first-order reality for you?
In the context of software development.
You're not all sleeping, you're allowed to answer.
I heard 'code' in the back.
The product, that's an interesting remark.
In relation to what I said, what is the only tangible reality, we could say tangible, in software development? It's true that the product is also intended, I think. Yes, I am... Yes.
After that, this is where we see that there is always a notion of perspective in all these discussions. Depending on the perspective, reality will not be the same. As a developer, sorry, I'm going to defend my parish, for me, it's the code. Why do I think it's the code? Because if you've worked on large legacy projects, it often happens that someone arrives saying how it works, a ticket or something, who no longer even knows how it works, and in fact, the only reality is the code. And sometimes, there are even people who think the software works, well, the tickets, the business experts think it works in a certain way, but in the code, it works in another way. And that's the one that's in production. The only reality is the code that's in production. So that's why I think the priority is the code. And the second reality, I've dismissed the product from the question, I've avoided that difficult debate, the second reality is this, it's the specs. That's a good second reality, very subjective, depending on who reads or does what, we will have a completely different reality. And I really like this... drawing joys from the code, is that I can't read specs. I admit it, it's a public confession, it's the people who have worked with me who end up knowing it. I practically don't read the specs, in fact. I prefer to discuss them with the person. And another image we all know, which explains these subjective realities very well, is that there was a need, and then depending on the salesperson, the client, the developer, the operations, each has a different vision of this reality which is the code.
A solution? Well, who doesn't know? Come on, let's say that. Does everyone know? Very well, I won't teach you anything, we'll go quickly. So, it's BDD, it's this mindset of defining a need as simply as possible according to three states. Actually, according to a starting state which is the context, with an action, a behavior, hence behavior-driven development, and then an expectation. And that's exactly what we do in a unit test. We put ourselves in a state, we run the method or function, and we expect a result and we test this method. Just so you know, if you want to present it, there will be slides. If you want to present it to someone who doesn't do it, I shamelessly took this from Gojko Adzic's *Specification by Example*. It's that you have BDD examples that turn into acceptance tests when you automate this BDD. That's really the point, which describe the business specifications very clearly, very succinctly, and very neatly. And in addition, with these acceptance tests linked to BDD, you see, testing the business. So if you have everything in BDD, you have something that might be a bit more tangible than code for someone else who is a developer, and which remains entirely tied to the reality of the code. That's why I find it very interesting, perhaps a way to present it to spread BDD when people wonder what the point is. And I'll leave it at that because I can't defend it, I'm sorry, so I'll let someone else take over.
I like doing the minimum viable home for several reasons. Especially among developers, there's always a certain myth about the real cycle, and everyone has also had the chance to work in a real cycle mode, with real processes and all the artillery that can be deployed in very large organizations to try to control what we end up with. In a complete V-cycle, theoretically, we're supposed to have this. And the most important thing in this diagram is the horizontal arrows. It means that for each of the steps, we're supposed to have another step that will verify what we specified, what we designed, analyzed in the left step. And the idea is to have... Well, the feedback isn't necessarily that fast, but what you should also know is that tasks, for example, on requirements analysis compared to the preparation of test books, just like, in fact, we'll see the specification of validation tests, are things that can be done in parallel. So that's something that's often forgotten. But that was also why we started working like this. The first line of defense against the cognitive biases we can have in the different steps. It means that why do we verify our spec and why do we verify that our project is valid compared to what we specified? It's also to see if in the way we understand the specification, if it really respects what we specified. It's also that we know there are judgment biases, there are biases during the analysis when we formulate the need. Especially since the higher up you are, the more experts make the decisions.
And they are biased.
There you go, they are also biased by their own experience. They tend to feel like they're always right. Or at least to be overconfident. And then, as we'll see right after, it's an example of bias we can have at the analysis level, the Dunning-Kruger effect, which says that in fact, people who have more skills tend to be those who underestimate who overestimate the difficulty the most, and those who are the least competent tend to overestimate their ability. And so, both in complexity and in specification, we'll have big divergences, and consensus won't necessarily be reached with the most experienced people, who are the least likely to be wrong.
Is it going okay?
Yes, it's going.
The idea is also that V-cycles can be done in cycles that are specific to detailed design, but also to architectural design.
Of course, all this assumes that the specifications don't change.
That's one of the reasons it only survives in the industrial field, because most contracts and deliverables are based on specifications and interfaces that are made not to change. And sometimes, there are projects where, when we have projects spanning 30-40 years, we avoid doing things that are too flexible.
However, what I prefer is still this.
The whole point is also to be able to do quick loops, to test things. And for me, Yannick's solution is rather BDD, what he prefers the most. For me, in fact, I rather try to influence processes based on the project, based on the people. Because for me, in fact, those are the things that determine the most. And people who can't work in a Scrum approach, people who can't work with a V approach. And the most important thing for me is to have a process that allows two things. First, to be able to respect the different constraints we can have on deliverables, specifications, but also to have a part on experimentation that will allow us to do more interesting things at the product level, and not just at the code delivery level. Because, for example, the approach in this form for coding is rather that we are in an exploratory phase or that we are actually looking for disruptive innovation, not necessarily capitalizing on... A large existing system, but a large legacy. We'll have a hard time working this way.
And just to explain something very interesting that was explained by Eric Ries, it's that we move away from... When he sold it, it was for startups, even though in fact, I think it applies even more in companies. But he said, startups are something, there's a lot of gut feeling, a lot of emotion and system 1. The idea is to use data and this reflection linked to data and the stage to move away from system 1 and enter system 2.
The most important thing, in fact, is to... Regarding reasoning and the psychology of reasoning, which is the theme of the presentation, it's that based on facts, we can't make judgments. Well, some do, but generally, they are very well paid.
We sometimes let them.
We'll quickly go through the rest maybe because it's true we don't have much time left.
Some examples of biases we can encounter are, for example, conflicts of interest, where we tend to sometimes favor our personal interests, to make certain choices,
whether in analysis or design, we can have the illusion of knowing or the fact of having done a project a few years ago that used such and such a technique, it will... Certainly encourage us to reuse it, even if it's not necessarily the best way to do it. Blind spot bias is ignoring the cognitive biases that will be present throughout the project, and even daily. The Dunning-Kruger effect, I already talked about that. For example, in the code debugging phases, we'll have selective perception, where we really choose,
We perceive only the things we want to see, cognitive dissonance, that's not bad at all, it's actually adjusting to reality. I found a good example to illustrate this, for example, we tell ourselves, okay, I'm motivated, I went on a diet, I'm going to stop eating pastries. And then we tell ourselves, no, come on, I have the right to cheat sometimes. And the next step is, okay, I'll eat pastries, but I'll do 30 minutes of exercise afterward. But we know full well that's not going to happen. It's a way of trying to reconcile with reality regarding the commitment or at least the decisions we had made beforehand. The illusion of series is simply when we see frequent occurrences, we get the impression that it becomes something that can be systematic, and we can assume that if we had, for example, two errors in a part of the code, that it's something that will happen all the time, and in fact, it might just be a circumstantial behavior.
Or conversely, for those who do multithreading, we have the impression that it works.
Regarding retrospectives, the most common is self-complacency. We are always proud, we always highlight our successes and not so much our mistakes. We have the bias of immunity to error, it's never our fault. So that's the most common. And what I like is that there's always someone in the retrospectives who says, 'Yeah, but I wanted that by the way.' It's always easier to say after the fact.
Do you want to start or should I?
Yeah, I'll start.
If you want, I'll do it. Ah yes, so this is where you'll understand psychic negentropy.
Yeah, so I saw you mentioned a few names. A Slavic-sounding name with perfection. I'll let you take what you want.
Okay, I'll do the slide, you help me. So, Milaïs Kizun... No, I won't manage it. It's dead. So, you'll try to do it at home. It's a little end-of-session exercise. He's someone who talked a lot about gamification and flow.
He's one of the original authors of gamification. Go ahead, I'll let you do the rest.
So the idea, in fact, is more in the context of productivity related to games, even though in fact it will come back a bit later for the part gamification, let's say, is that the idea is that to achieve maximum productivity, you need to create a state that he calls flow, where you find the right balance between simple things, which we are very confident we can accomplish, but which can be boring and tend to distract us, compared to a degree of challenge. It's that as soon as it starts to get a little complicated, we are in somewhat familiar territory, we start to get a little anxious, we pay a little more attention, but if it becomes too difficult, that's when panic sets in. So the idea is to either alternate, to some extent, or try to maintain this line, this good balance between difficulty and simplicity, between things that will be complex and things that will be simple, in order to achieve productivity and mental comfort when working that will be optimal. What we see in gamification is that if you play, for example, Tetris or Candy Crush, it's that at the beginning you start playing... The levels aren't very difficult, so it goes fast, and you start to feel a certain comfort. Then, at the end, you don't even think anymore. It's the part where it's a spinal reflex that takes over. We just operate on visual automatisms. We feel like time is passing, and we don't even realize it. We actually reach what was called back then the Tetris Trance. When you reach level 99, the pieces don't even appear anymore, but you still place them in the right spot.
So to continue, as developers, since most of the room are developers, we know all this, you have stages. In those stages, I feel compelled to listen to music. Often, it's techno, pretty fast trance music. Some people might be more zen and all that. And then sometimes, you have bugs or exceptions. And there, you're kind of in between. And on a normal day, it's in between. So, who works with Java?
Okay, well, we've all encountered that. So what do we do in those cases? I know a bit about it, I'll put it here too, it's the public confession handle. The first thing is that I reboot, so volume 4 or something like that, we start by restarting because systematically we think, system 2 I say I don't feel like working, we say okay, it will work again. The second solution is that we try anything and everything. We try to look everywhere. We go on Stack Overflow, we try to find the first copy-paste we have. Do we have a solution? The first one, I'll leave it, because it's Maxime's, he loves it.
This one is more about evaluations, when people are stuck on problems. Very often, they try to bother friends who are in full flow mode, you must not disturb them at all. This is actually about using the rubber duck, and the idea, actually, is in rubber, why not. The idea is that simply explaining the problem, forcing yourself to describe it step by step, and covering all the context, will unblock you from judgment biases, the various other biases that make us focus on one part of the statement or situation and prevent us from finding the solution. Sometimes, even when you go on Stack Overflow, you start writing your question and before you finish declaring the question, you will find the answer simply because you have reconsidered all the steps that happened before. It's very useful, both for thinking and for launching with colleagues.
And just to finish, actually, just before, you were in pure system 1. What can I do quickly, without thinking, here? What can I do? And actually, the act of talking gives you time, and you start to visualize, to begin thinking. And actually, to explain all this, there is a short course, we will have a link session at the end. On Coursera, it's well explained. They explain, there may not be precise neuroscience research... But in reality, they explain, but it's a principle we know well: you have an exception, you try to figure out where it comes from, then you get stuck, there's a network, a set of neurons that activate, but it's not the right ones, it's not what we would like to remember. And then we should... Really, go and hit that to remember, oh yes, I need to do this, it's this piece of framework that isn't working, I remember now. And actually, if you go do something else, often sleeping at night, taking a shower, some say go do sports, go for a jog, it will allow you to clear your mind, and if you restart your thinking, you will activate other neural networks and maybe find the ones that work for you.
It's a metaphor, but a very beautiful one, I find. Another thing, there's the rubber duck, if you're a bit more social, you have the father as a friend. I don't know if everyone does the father as a friend, I don't do it very often either. I think it's extremely interesting. Afterwards, in terms of flow, there are also advantages. It's that if you want to enter a very sad 99 mode, you won't be able to have it. Is it good, is it not good? It's a question we could discuss with people who love the father as a friend. I haven't done it enough to really judge, but I think you have to be careful about the biases we might have by saying the father as a friend is great, I do it all the time. But have you reflected on the disadvantages or advantages? But it's valid for everything. We can ask the question, yes, quickly.
Yes, mob programming, I won't talk about it. We could have the whole team around a problem. Similarly, you shouldn't do it all the time, because in my opinion, it becomes crazy. I think that's it. Just to summarize. The big summary, if you didn't understand, is to take an interest in psychology. It's super important. Here, we just scratched the surface of the topic. It's an extremely interesting topic that will help you understand many things.
Don't waste time estimating, it's useless, but Vasco Duarte said it 100 times better than me, 100 times better than us.
Try to bring together these two levels of reality. Go read Paul Watzlawick, it's extremely interesting, it can be read in two evenings, he has small books. And learn to manage this energy and your systems 1 and 2 in everyday life. Remember this metaphor, it might help you in the life of a developer or when talking with your manager or colleagues. A few links, so Thinking Fast and Slow, it's the big bible that everyone references. Paul Watzlawick has many others, notably How to Succeed in Failing and Finding the Ultra-Solution. It's very good for those who have done MDA or large architectural systems. We look for the ultra-solution, we fail miserably. We didn't talk much about it, but he worked a lot on all the irrational behaviors related to everyday life. So, Dana Larelli, go check him out. And two courses, one that is very much a discovery, but extremely interesting, called Seeking One-on-One on Ed. And you also have videos on YouTube, if you search in the link, I'll put the slides, you have the videos on YouTube. And Learning How to Learn, which is a Coursera course.

Transcript (Translated)