Bruno Boucard & Thomas Pierrain
Transcript (Translated)
Who among you has already worked on legacy code?
Yeah, quite a bit. Who in the room is a developer?
It's okay, though. Okay. We're going to talk about Legacy, but not just about developers. Let me introduce myself, Thomas Pira, technical architect. I've been working in a large bank for over 10 years. So, I have some flight hours. In practical legacy code, but not only that.
As for me, I'm Bruno Boucard, same thing, I have quite a bit of experience with legacy code. Alright, well, that's enough.
So, legacy,
It often starts with a sad observation. We look at what we have: the codebase, the teams, the people. Sometimes, it looks a bit like this.
Sometimes, it's situations that we really can't understand. The code lies to us; what it tells us is not what we observe. People haven't necessarily remembered what needed to be done. We don't all understand each other between business, development, etc. It's a bit complicated. In some situations, it's even worse than that. It's completely absurd.
We're going crazy.
We're going crazy, yes. So, in short?
In short, we run, we run, we run, we do sprints. And in the end, we're exhausted. And what's worse, in the end, we get a pile of mud.
It's a bit of a mess.
And the worst part isn't so much that, but that it costs us a fortune.
Not only did we produce something that wasn't maintainable, but it costs a lot, a whole lot.
It's expensive for companies, so the bill like that, it also costs a lot in people's heads and morale. The number of colleagues I've seen...
The moral and behavioral damage... Even if they aren't clearly expressed, they exist and are sometimes serious.
Imagine if we all managed to work hand in hand, united by the same goal, that wouldn't be bad at all.
So, in your opinion, where does legacy come from? Well, I thought about it a bit, Bruno, before we met.
Yeah, yeah, yeah, I know.
I have a few suggestions for you.
Yeah, go ahead.
Legacy, it's mostly the others.
Well, of course.
Yes, you arrive on a project, the code is there, it was other people who did it, frankly... No, that doesn't cut it. Legacy is linked to our industry.
It's a bit like coffee shop talk.
I'm sorry, I didn't have much time to digest it. By the way, we're the only industry that talks about legacy to refer to negative things, it seems to me. In all other contexts, it has another meaning, another flavor, this term. Well, so there's a bit of that.
There's a bit of that, but I don't feel it's the right cause.
Alright, okay, I'll try. Legacy, to me, is like a curse. It's all that comes back; we observe it in almost all projects, even for young projects, after a year, two years, sometimes we're in a legacy situation. By the way, what is legacy for you? Do you have any small ideas? How would you characterize it? What is a legacy application or context?
Other people's code. The code before the pain. That's not bad. Yeah. Do you agree?
Code without tests, that's Michael Feathers' definition. Well, I have another one that's personal: it's code that causes suffering, or a situation that causes suffering. Whatever the origin, we suffer. Whether it's related to the code, the business, the context, etc. So, aren't you convinced?
No, no, no.
So, in your opinion, we've seen what it is, but where does legacy come from? Any small idea?
Still nothing?
Yes, actually, that's not wrong, Christophe. But actually, it's us. It's you, it's everyone, in fact.
Legacy is you, well, it's you and then it's us, it's all of us in this room. If these situations repeat over and over, we're part of it. So, legacy is a bit like when you have a kitchen in this state and you keep cooking.
It's absurd.
We don't do that at home, I dare hope for all of us, but we do it at work in some cases.
Legacy is also a situation like that, where we tell ourselves we don't understand what needs to be done, but we do it anyway. Because if it turns out, if we stop, like in the hospital, if we don't press the button, something serious might happen. So, we're all involved in this... So, it's all of us. And then it's the code and us around it.
Yes, exactly. And well, there you go, pumping to do something whose meaning we don't understand is unfortunately the lot of many projects, many organizations.
And it's a shame.
The context, it's been years since we've been saying that software is eating the world, Marc Andreessen said it, etc.
Do you feel that we are up to these challenges? Today, everyone in this industry.
For us, we consider it's about time to change our posture. That is, the answers we provide to today's challenges are clearly not suitable. And these recurring situations of suffering, of mismatch with expectations and expected values, etc., we need to get out of them. So, can we say, are you ready to follow us? It seems there was something, maybe after. We're going to do three chapters. We're going to do chapter 1, it's culture.
Yes, communication and culture. In fact, I was quite shaken up while reading the book Sapiens. And at one point in this book, he says there was a period among the first humans, the first sapiens, the hunter-gatherer period,
A little nod to Pablo. Where humans were almost in a humanist stance of sharing, and they didn’t necessarily have issues with domination. And things were going rather well.
We are social animals. Why doesn’t it work out smoothly anymore?
We’re no longer in the same context. We’re in companies, in teams. Why doesn’t it work out smoothly for us anymore?
Because, in fact, I often ask developers questions. What is their application for? They struggle to answer me. So, there’s a loss of meaning, a loss of motivation.
The loss of motivation often comes as a consequence.
Yes, it’s related, of course. And above all, there’s no communication, or at least not enough. So, as a result, we’re a bit like a radar without an echo. No feedback, we’re lost. We’re on the verge of disengaging.
Without feedback, where do we go? We try, but well. So, the first step when facing a somewhat painful legacy situation is awakening.
So, awakening.
Awakening is about restoring the connection with the business, and that’s really complicated. Who thinks it’s complicated to restore the connection with the business when you’re on the dev side? Yeah, I’m not alone, that’s good.
So, communication is important. Communication isn’t about information—it’s not just throwing something over the wall and hoping it’s received, and if it’s not, too bad. It’s truly bidirectional; we make sure the other person understands what we just told them. And that’s key, and it’s rarely used even though it’s quite powerful. The first reflex as a developer, it’s Jérémy Grodzinski, with whom...
we interact a bit, who says it’s always about understanding the domain. Before coding, the primary job of a developer is to understand the domain they’re working on. It may seem obvious to say that, but in fact, it’s very rarely observed. At least, in the projects I’ve worked on, it’s quite rare.
Understanding the other person is also about empathy, and that’s important. So, we’re all more or less capable of showing empathy, meaning putting ourselves in the other person’s shoes. I even read recently...
You told me about Nordic countries where they teach empathy courses.
In Iceland, I think it’s in Iceland, where they teach empathy courses in school. So, apparently, it can be learned.
And they seem happy; they seem to find it meaningful. So, showing a bit more empathy when it comes to the technical side in relation to the business doesn’t hurt us. Generally, the results are nice.
And then, if the other person doesn’t want to, because sometimes we want to understand the business, talk with the business side, etc. Sometimes we’re a bit confined, restricted; there are many intermediaries—business analysts, product owners—there are many intermediaries between the domain experts and us who will implement it.
So, what do we do? And sometimes they don’t even want to collaborate, meaning when we end up in the same room, that magic I was talking about at the beginning doesn’t happen—the rugby team pulling together in the same direction.
There’s a phrase, for me it’s in the form of a punchline from Alberto Brandone, who was here this morning for the EventStorming, which I’ve used many times in many contexts, facing people who don’t want to explain what they’re doing so we can implement it, it’s to explain to them very sincerely, it’s not what you already know that will go into production, it’s what the developers have in their heads. So if you don’t help them change their mental models and what they’ve understood and what they have in their heads, everyone will lose out. That little phrase, honestly, has gotten me out of workshop situations where everyone was just staring at each other in awkward silence.
It’s quite practical. So, if the other person doesn’t want to, that’s it. So, EventStorming, we talked about it this morning—the picture is getting darker. I don’t know if you’ll be able to see anything. Who was at the EventStorming this morning during Alberto’s workshop? A few. What is it? It’s an exploratory way to understand what brings value to the business. We have technicians and non-technicians in the same room. We use Post-its on a large surface. And through these possibilities, these are business events, things that bring value. We start from an event, for example, payment received, and we try to say, well, what happened before? What led to that event? And so on, and so on. Step by step, being on our feet and working on a large surface allows us to use non-verbal cues and better understand when people disagree. And it’s a way to have fairly quick discussions. Because what’s important, Bruno,
What’s important is to have good conversations. Not necessarily fights, but to explain things well. And if I can draw another parallel with Sapiens, it’s that we, as human beings descended from Sapiens, have an easier time understanding examples rather than abstractions. So, obviously, academic works are often more focused on generic formulas.
It’s clear that we, as human beings, prefer to have examples first before moving to abstraction. So, having conversations illustrated by examples is essential. It helps us understand.
I’ve seen a number of projects where we started directly with abstractions, thinking we immediately understood what needed to be done and trying to figure out how to build the solution and find the right abstractions when we hadn’t really understood the need. So, starting with examples to abstract later is quite important. In this discussion with the business. Another important thing is to act at the cultural level, because culture, as the saying goes, eats strategy for breakfast every morning. If you don’t act at the cultural level of your team, the teams around your business, it’s going to be a bit Sisyphean. And very quickly, the habits of the minefield, of the legacy, will return. So, act on the culture. So, how do we act on the culture? I think it’s Nick. who spoke yesterday. A trick is that no one is a prophet in their own land. You can have great ideas, you can have a vision, you can have all sorts of things. If it’s you, who’s been within the walls for a long time, who formulated it, generally you won’t really be heard. So, you really shouldn’t hesitate to call on people from outside. There’s the consultant version, etc. There are also simpler ways to wake up your dev team, for example, what we call brown bag lunches. Who knows what a brown bag lunch is? Already quite a few. So, what is it? For those who don’t know, it’s when you bring in an expert or a speaker during lunchtime. You just treat them to a sandwich, and they come to talk about their passion, something that interests them, or a feedback experience. And it’s an opportunity for you to step out of the context, for your colleagues too, to wake up a bit by seeing that other people work differently and do other things. And it can give you ideas afterward, internally. So there you go, it's quite simple to set up. All you need is a meeting room. A Barco or a pico projector if the meeting room isn't equipped. And it can bring a breath of fresh air to your dev team. So don't be ambitious and think, 'Hey, I'll book the CEO's meeting room and then invite everyone.' You'll have a bit of trouble doing that. Start by doing this at your team level. Schedule a meeting at lunchtime from time to time to do this kind of thing. It's quite appreciated; it's rare that it doesn't catch on. Besides, it's on a voluntary basis, it's free, it's on a voluntary basis. So people come naturally.
I'm Bruno.
Well, you actually need to be curious, practice, and be oriented toward others. It's an excellent way to change by learning and exchanging. So, indeed, there is a document that exists in programming which is...
You won't read much; we'll read it twice for those in the back. The first is that you are not your code, meaning when you do code reviews, etc. You shouldn't feel attacked if someone criticizes your code. What's being criticized is not you, it's your code. So you need to take a step back from that.
The second says that... Just because you feel a bit strong doesn't mean there isn't someone who knows more than you. So there's no need to show off. It's better to stay humble; it will be easier to collaborate.
The third is quite specific to what was in extreme programming, which is to say that the only constant is that the world changes. So try to get used to it. The number of people and colleagues I see grumbling when something changes, instead of seeing it as an opportunity, it's just a mindset, but it can change a lot. Just welcoming each change as an opportunity to do something better, to do something differently, and to find other ideas.
Yes, well, don't be the developer in the back, next to the radiator. That didn't necessarily help with communicating to understand the domain.
And then when doing code reviews, while you should be kind to people, you should be tough on the code. When doing a code review, you have to say things, you have to put in the effort. But you have to go for it. So kindness doesn't mean accepting everything. And then ending up in situations where after a while, people can't take it anymore like pressure cookers. They haven't been able to express something that has been bothering them about the project for a long time. And it leads to disaster.
Well, and also, don't rewrite things without consulting people, colleagues, don't do things solo, in the corner. as an opportunity to do something better, to do something differently, and to find other ideas.
Yes, well, don't be the developer in the back next to the radiator. That didn't necessarily help with communicating to understand the domain.
And then when we do code reviews, while you have to be kind to people, with the code you have to go for it. When you do a code review, you have to say things, you have to be diplomatic, but you have to go for it. So kindness doesn't mean accepting everything and then ending up in a situation where, after a while, people can't take it anymore like pressure cookers, they haven't managed to express something that has been bothering them for a long time on the project, and it leads to disaster. Well, and also, yes, not rewriting things without consulting people, colleagues, not doing things solo, like in the corner.
So, software craftsmanship, who knows about it?
So it's a culture above all, it's not necessarily technical practices. So it's passion, discipline, motivation, efficiency, but above all, transmission. So that's important, it's passing on this passion to others.
What's important is that it's not a set of practices.
No.
that you can read here and there on Twitter, etc. It's truly a culture, it's loving to learn and loving to pass on knowledge.
And loving to improve. Moreover, progress is made simply through observation, improvement, observation, and so on. We're quite close to the spirit of today's event.
That's also what software craft mentoring is. Oh yeah, Bruno?
Yes, that's often in the... My job, every day, is more like coaching. And it happens that the team, and for all coaches, this has often been the remark. I don't need it because at our place, it's different. It's more complicated than others. This answer has to be, at our place, it's different.
Who has thought that to themselves from the start? That small step seems nice, but at our place, honestly, it's not possible.
No? Okay, that's fine. You're shy, you know?
Yeah. Impossible to regain control? Yeah. So, that's something I really like, in the 16th century, there was a young Frenchman, 18 years old, who wrote a short text that in some way changed the face of the world. Well, that sounds a bit... Grandiose without a phase, etc. But what does this short text say? This short text says that others only have power over us if we consent to it. So, basically, this text says, 'Be resolved to no longer serve, and you are free.' It's La Boétie and his Discourse on Voluntary Servitude. It's a short text that was taken up and partly triggered the French Revolution.
All emancipation movements, whether against slavery, for Black people at the time, apartheid, the greatest theorists or the people behind them all said they were inspired by this little text. In psychology, the same, when we talk about victims, perpetrators, etc. This text truly transformed. shaped many things. Imagine, at 18 years old, the guy, in the 16th century, at 18, writes a text like that. Well, La Boétie is still La Boétie, but with our little computer problems, etc., we think, with Bruno, that we're capable of doing something. There's nothing impossible about the situations we're experiencing right now.
So, chapter 2.
Chapter 2 is about practices.
Yes, we've talked a lot about communication, posture, a bit of humanism. At some point, we're still practitioners, we write code. So, to do it correctly, you actually have to read, discuss, rephrase, look for metaphors, and propose.
All of that belongs a bit to the book on domain design, but there's no need to read the book, it's still common sense and it still allows for a better understanding of the need in order to code correctly.
Who thinks we sufficiently focus on the domain, the business value, well not the value, but the business logic, in any case the business at the heart of our developments in projects? One, two, three who think that?
Yes, because in most cases, the situations I observe at least, it's the temptation, when we don't make enough appeal to our curiosity, in any case when we don't put that at the heart of our decisions and developments, it's to find a situation where as a technician, one can feel a bit undervalued. I'm a developer, I don't always have access to the business, there are so many intermediaries. and sometimes I'm even asked not to go to the business, it's a bit demeaning. So what happens? What I've observed, as a technician, is that we tell ourselves, since it's not very rewarding, I'll try to find another source of validation. I'll become a super expert in something technical. And okay, I won't be part of their meetings, their workshops, etc. But at least, they'll recognize this expertise. So we'll hyper-specialize and fall into a kind of comfort zone where as a developer, we'll be more interested in technical frameworks, libraries, rather than the new business or the business we have to work on. So the caricature, I don't know if you've seen it, Mr. Manhattan, is the guy who knows everything about everything.
The caricature is becoming a bit bitter and getting stuck on that very technical thing. And then, since we don't understand the rest anyway, they're idiots, they're this and that. We stay in the ivory tower and focus on the technical part.
We're a bit cynical.
Yes, that's the next stage, the state after. Who has encountered people like that in teams a bit? We're not alone. It happens. We're not too...
It happens, it happens.
We talked about practice.
There are still some fundamentals when you want to write code that isn't legacy. It's actually applying some principles. So, KISS, the double loop. Knowing your keyboard shortcuts, doing pair programming, not using a framework just because it's trendy, and knowing the basic principles of object-oriented programming if you're doing OOP.
It seems obvious, but it's true that the number of colleagues I've seen not mastering their work tool, that is, their IDE, shortcuts, etc., and being stuck, being tense because they didn't feel up to par, when all it takes is a bit of practice. We'll see it later, but there are ways to improve on these small gestures to be able to spend your CPU, your brain, on other things.
There's a work that is somewhat a reference for code exercises called Kata, so repeating movements like in martial arts to get automatisms.
It's a way to practice daily and improve today. It's not the only exercises that exist in the world, but it's a good start.
Are there any developers in the room who regularly practice code katas? Yes, still. We're at a conference, so it's not surprising. But it feels good and it's not that complicated, not that long. Otherwise, would you do that?
I have vertigo, so clearly never, never in my life. Even looking at the photo makes me feel weird. When facing legacy code, I prefer to protect myself. When I go to attack the legacy code, I protect myself. Well, not really like that, more in Arnett test mode. Arnest test.
So, we don't attack the Legacy without having a minimum of security.
That's the first point. The second point is that we must recognize our adversaries. That is to say, there's nothing to be done, we're in hostile territory, the code was done any which way, there's no business sense, so we'll have to, a bit like the rules of the road, know the signals that will allow us to have good reflexes. So we won't list them all, but there are a few.
They have little names, it's called code smells.
Yes, it's code smells. It's a somewhat emotional image of bad odors emanating from the code. We can take one like, I don't know, we can take the case of Feature Envy, for example. Feature Envy means that we have a portion of code in a method, for example, that is very envious of another class that exists in our code.
That keeps calling it. Yes, exactly.
It's a principle of responsibility, in fact. We have a responsibility that isn't in the right place, and so we've qualified the problem with a name.
So that simplifies the way of doing things.
Could you maybe show us that in code form?
Yes.
I reassure those who... don't code, what Bruno is going to show you is painless. We'll try to explain, I'll try to explain what he's doing and what you'll have before your eyes. We've done it once before, we managed not to lose non-developers. We can't see your IDE, though.
Yes, I'll stop.
Bruno is going to show us an example of code that comes from a code kata, a small coding exercise.
Which is widely used by coaches.
It's a rental code kata. Do you remember before Netflix, there were stores where we rented DVDs?
It comes from that business.
Yes, almost 15 years ago, there were people at the corner of our street renting DVDs.
In the evening, we didn't necessarily know what to do, there was nothing on TV. We'd go down to rent a movie. Basically, that's the functional context. And we're in the method that will print the receipt after rental.
I'm returning my DVDs and your method will calculate how much my bills cost.
There you go, it does a number of things. I'll try to illustrate what it does. It's interested in all my rentals to know how much each rented film costs. There you go, I have a little... A little message. Output. Alright, OK, I won't start anything.
And then, I have a second point. I don't know what's happening there. Which calculates the loyalty points. So, there are two lines of calculation. Three.
Wait, while you close the error, actually, there's a for each in book that says, for all the films you just returned to me, I look at each one, here, I look at the type, and if it's a regular film, you'll have to stop that, Bono.
I don't know what that is.
It's as if you're trying to start a debug, I think.
No, but I'm not doing anything, I'm not even touching the screen.
Yes, hide it. He might have trouble typing.
Yes, but it might be modal, in which case I'll have problems. It's modal.
If it's a regular film, it will deduct a certain amount, with a very particular algorithm. If it's a new release, it will deduct that. If it's a children's film, it will deduct that. Right after calculating all that, the loyalty points will be calculated based on the activity.
And finally, we'll format the receipt specifying the amounts.
I assure you this isn't a prepared script.
It's quite incredible.
It's as if someone was typing on my keyboard.
That's it.
I'm not touching anything.
That's right, yes.
So, we'll try to take a metaphor. I'll leave it for now. Imagine that in your living room, you have the dishes. You find that, it's not bad, but there's still something that's not right. And your wife arrives, you've just moved in.
I had that in my first apartment. Sorry? I had that in my first apartment.
Yes. And despite everything, you have a kitchen. And in my opinion, from the first evening, you'll move the dishwasher into the kitchen. In fact, it seems pretty logical. In code, it's often like that. We often have a dishwasher that is found... Right in the middle. Well, it's not necessarily materialized because it's not encapsulated in something. There isn't, let's say, a physical element that surrounds the portion of code. But ultimately, it's almost that. And it's the code I was mentioning, the feature envy. That is to say, we indeed have code. That has no business being there. I don't know why it...
If you hide the message, scroll up a bit more. No, I can't.
It's modal.
No, if you scroll up a bit more.
Alright.
Just so we can see the Feature Envy. Yes, yes.
So, typically here,
Put it at the bottom next time it appears, just so we can see. So here, we go through each rental. So, it has a terrible name, it's Itch. So, the first thing we could do is change it. If you have control... We can call it rental, meaning location. That will clarify things a bit, because you see, we have it everywhere. There, watch out, he took control back. And so the rent, rent all there, we're in the customer class. I don't know if you see, but we're in the customer class. And the customer keeps calling logic that's in the rental. So there's coupling, a dependency between the customer class and the rental object. That means this piece of code...
Actually, we don't see it very well, but there's a rental class. So we could imagine moving this portion of code to the right place.
We're taking this example because it's relatively simple, but if we take real legacy code, we'll find this situation regularly. And the difficulty is that here, despite everything, there are class names that are roughly correct, but in real life, we won't even have that. We'll have classes that aren't properly named. We'll see later how we can manage that. But here, just in relation to my... To my metaphor of the dishes. I need a membrane, I need something that allows me to create a boundary for the code that's not in the right place.
So there, you're going to make a box, you're going to put the dishwasher inside.
Exactly. I'll try.
The box is called a method. He's going to do an extract method. Everything that's selected there will be put in a place we call a method. So the box. And once that...
I'll call it Computer Moon for now, which will ultimately be sufficient at first to move the code.
When working on legacy code, we're not forbidden from improving readability, meaning naming. Naming is key because we spend 70% of our time reading code. Compared to writing it. So it's important not to read nonsense. I said the code lies because we often have terrible names.
So once we've done that, we've taken the portion of code that wasn't correctly placed and encapsulated it in a method, but the method is still in the wrong place. We need to move it to the right class.
You take the box and you put it in the bathroom or in the kitchen, in this case.
Meaning in the Renthal class?
Yes, in the Renthal class.
to move the code.
When working on legacy code, we are not forbidden from improving readability, that is, naming. Naming is key because we spend 70% of our time reading code compared to writing it. So it's important not to read nonsense. I said the code lies because we often have lousy names.
So, once we've done that, we took the portion of code that wasn't correctly placed and encapsulated it in a method, but the method is still ultimately in the same place. It needs to be moved to the right class.
You take the box and put it in the bathroom or the kitchen, as the case may be. Meaning in the Rental class?
Yes, in the Rental class.
So now, he's in the process of moving it.
Using the tools. And there you go, so you've moved the code. So here, we're still on the Customer class, and we see that the method has disappeared. And it's in the right place.
There you go, so now I'm actually in the moved method. Actually, it's this thing here that is... That's what it is... I found it more likely to show it. Don't click.
I no longer use a laser, so I am the laser.
There you go, so the element has been moved, but there's still an aberration. The aberration is that the method is now in the Rental class and receives a rental. The method is static. We'll make one last move so that the method becomes non-static.
So now, you remove the box, you're sort of making permanent the fact that this logic is now in this place.
And so in the original code, now we have the instance of the item from the Rental collection calling the calculation.
Just a small example, do those who have never coded understand a bit what we just did or not? Yes? Okay, that's good then.
So when we work on legacy code, we spend our time saying, hey, what is this thing? Why is it there? First, we can name it better and move it.
So that was Cosmel. We saw the first part on culture, the second part on practices. So the third part, we're tackling the tough part of the subject.
To the assault.
To the assault of legacy, we get in the van and off we go. Off we go, off we go, off we go. So where do we start, Bruno?
It depends a bit on the area to work on. So always, indeed, we are motivated to put value first. That doesn't change.
I have still seen refactoring projects, so we change the internal structure of the code. That were not always motivated by business objectives.
Not here. It can be an opportunity because we know we are going to implement a new feature in a portion of the code. And so, we try to clear the space before integrating the new feature.
So, a bit like before painting my living room, I sand, I do the fillers, etc. It's preparatory work. But it must add value because otherwise, it shouldn't be done. If what we do doesn't have... It has no value, so it's better not to do it. It seems obvious, but the number of projects where I've seen actions like that, we didn't know where we were going.
Often, we get the remark that at our place, not only is it different, but the code isn't refactorable.
It's easy, you showed us a small crappy example, there were already tests, but if my code isn't testable, that's a bit what we hear. Same answer, not testable.
So yes, there is still a paradox.
Yes, there is a paradox because on one hand, we want to write tests, we want to refactor. But we can't refactor without tests. Well, there you go, it's a bit paradoxical. So, the question is, how do we go about it? So, how do we go about it? It's that at some point, we'll have to jump without a parachute. Without a safety net. But we won't do it just any old way. We'll do it by following patterns that will allow us to manage this risk. So we will scrutinize excessively all the modifications we make. We will keep only one objective at a time. We will never change objectives during a modification. We won't change public contracts, and we will indeed rely on the compiler because that's all we have left to check if we're not breaking everything. Another element is that we will prefer to do it in pair or mob programming to ensure we don't make mistakes.
We will relieve some of the pressure anyway, because when we touch legacy code, there is business value, there is production behind it, generally. So doing it alone is a lot of pressure. So doing it with others is already a guarantee of serenity and also efficiency.
There are especially some techniques, because here it's about the first steps where we really have nothing, so we need to move forward a little to introduce our first tests.
But there are techniques to break our chains, break our dependencies. What is a dependency in the context of legacy code?
A dependency is ultimately the fact that the code depends on other code which itself, sometimes indirectly, depends on the starting point. So we have cycles, it's very difficult in fact. To start testing. That's why breaking this kind of dependency allows us to isolate and introduce a first test.
Independence, it could be a database, a service, data problems?
Yes, a database. In fact, anything that doesn't allow us to guarantee stable execution. That is, if I run it once, I get one result, and a second time, I get a second result, the test won't work. So, we need to become independent of dates, threads, static calls, lots of things.
So, likewise, there are many techniques. There are a few that are displayed here. We could have done some live coding, but on some advanced techniques to really, even when the code seems untestable, static variable, dependency on a database we don't control, etc. Just know that there are always solutions. For those interested, we can discuss it afterward. But there are always technical solutions to free ourselves from these chains.
So, how does this translate into music in real life? These are techniques, etc. What will the strategy be? We will retain three strategies.
We have classified three contexts, three approaches that roughly symbolize the most common cases.
What will take us a few hours, what will take us a few days, and what will take us a few months. We'll go with that. What will take us a few hours.
Yes, so a few hours and one characteristic is that we are alone. Meaning we don’t have what we call the domain expert with us. So, we don’t understand the code well. And so, we will use a technique called the Golden Master. Thomas, could you perhaps explain the Golden Master to us?
It’s a technique I really like. What is the Golden Master? It’s when I take some legacy code. I will clone it to have a new version. That will be my working version. Before touching anything, what I want is to obtain a working version that has the same behavior. I will consider these two portions of code, these two elements of the system, as black boxes. I will create a test that will, if I send these inputs into the two black boxes, I must have the same results in both cases. Meaning, I send an input into the legacy code, I get an output. I send the same input into my new black box, and I must verify that I get the same output. This allows Once we have this test, we can refactor, we can restructure, improve the code—the new copy, let’s say, is what we will work on—while ensuring that we respect the contract, the legacy behavior. So, we take no risk; each time we move forward with certainty, and it’s this test harness that allows us to do it. It’s all the more brilliant because it’s not necessary to understand the behavior at first. At the beginning? At the beginning, yes. The goal will be to re-grasp and understand a little what this code does to reappropriate it. But from the start, we can move forward safely, even if we haven’t understood everything. So, it’s a good starting point.
The other element is about an application. So, here, we have more than a few hours.
Here, it’s not a fragment; it’s a set of components. So, we are in a phase of broad exploration. Meaning, we will try to understand the overall kinematics globally. We won’t necessarily go into detail because what we want is... Since we don’t necessarily know how it works well, because the code isn’t very well written, as we said, it’s sometimes misleading, and this time, we will have a domain expert, one or more. We will establish conversations with them. We will be a bit... He is blind, and we are his eyes, and we will tell him, here, this talks about this, does that mean anything to you? Does that remind you of something? And at that point, he will provide functionalities, and we will try, in light of what he tells us, to find these functionalities. Which will allow us, once we’ve understood, to write the first test.
So, transcribe what we understood together through this exploration work, through a test.
There you go, and as always, once we’ve written the test, we will eliminate the bad code. Since we have the test that guarantees the behavior, we are no longer safe.
So, we did this on an application. Does this speak to you, what we just said, the type of strategy on an application? The exploration and then for... We will write tests. Yes, I see some heads nodding. So, OK. So, the third one?
It’s about a department, an information system, for example. Here, it’s much broader. We are not at all in the same considerations in terms of time. But it can indeed be a good approach if we know we will be hit by a new functionality that will affect the entire information system. And so, we will indeed need to rework the code upstream. So, we will apply the same thing as in an application at the level of each team, and we will report daily the changes we have made in a...
We work in parallel; each team works in parallel.
But we will try to homogenize the information between all the teams. It may take a little time, but it will be an opportunity to have conversations, to have ideas, and thus improve everyone’s work. Because the teams know each other but do not work together daily.
So, we work in parallel and hold retrospectives regularly to share what we have understood and what the other has understood and to resynchronize. Okay, so we can also...
So, this is something we were able to do with several people in a large red and black bank. The project managers were relatively appreciative of the developers' new skills.
Had you coached them?
Yes, we had coached them, etc. They had advanced refactoring skills. And they had the idea to gamify, across several teams, a real refactoring, where ultimately all day, people would work on refactoring with various points. The metrics were not necessarily equivalent across teams. And we saw teams doing it, but with real joy. Meaning, here, we were working on legacy code, management was happy, the developers were happy.
In short, a situation we could never have imagined.
It’s like a school fair, but all day, everyone works to try to clean up the golden courtyard as much as possible and create.
So, it’s possible. We can work on legacy code while being... We are happy.
It was complicated to convince the...
No, in fact, it came from them. It was the management that asked us. It wasn’t even us.
That’s what’s original. So, if it’s really a mess, if the experts have really left, they’re all gone, we have no tests, the business isn’t available, Well, then there are several possible strategies. In general, what people like to do is this. Blow everything up. You don’t see it, but it’s the end of Fight Club, where they are two watching the city explode.
The banks exploded.
So, that’s a somewhat easy solution. And for me, it’s a kind of anti-pattern that I’ve observed over the years. Meaning, I’ve seen many people do this. And realize after a year, a year and a half, that the code that seemed a bit weird to them, the legacy code from before, actually, they were doing things that weren’t so stupid after all. And that they end up redoing the same thing, redoing the same work of understanding, except that they had fun with new technological stacks, they burned a bit more of the business’s fuel to get there, they don’t care, it’s better for the CV. Less so for business value. But there you have it, so for me, I see this more and more as an anti-pattern, to redo everything from scratch. And another strategy that comes from the domain of Domain-Driven Design and Eric Evans in particular is called the bubble context. The bubble context is like a bubble of innovation, a bubble of clean code in an ocean of legacy. Here, you don’t see it at all, but there is a sort of legacy context that is a bit strange. And in fact, what is the bubble context? We will write code... In a clean way, we're going to do TDD, we're going to create tests, we're going to have semantics that will be as faithful as possible to the business, all of this within a sort of membrane. Why a membrane? It's so that the legacy code doesn't come and pollute the data models, the lousy terminology, so it doesn't pollute this new portion of code that will be inside the legacy system. So there's an advantage: it allows you to regain some pride, some confidence, some daily pleasure when you're working on a legacy application, sometimes for morale it's draining, so this means we can take control again, for example when adding a new feature, and we work with... today's standards, not those from 10 years ago, if the application is 10 years old, etc. So that, for morale, is good and quite effective. It remains to be seen what you're going to do it on, on a new value, on... Anyway, that's something to discuss, but know that it exists and it works rather well. So yes, to go from clean code to messy code, we have a sort of decompression airlock that we call an anti-corruption layer. And so, it will act like a decompression airlock that will translate the lousy model to the new model for you, to prevent the new model from being polluted, the new code from being polluted. So there you go, bubble, context. Time to conclude. First point, legacy is you, it's us, it's all of us. It's not the others. It's not those who were here before. Because, unless it's a coincidence, living the same situations over and over again, somewhere, we need to wake up a bit.
Yes, indeed, we need to be interested in the business, we need to give it meaning. It's even a constant posture, meaning understanding the motivation behind each thing, so as to create within each person a mental representation that can align with the business. It's indeed essential.
Understanding each other is the basis, but honestly, I see it very little. And then, train before going on the assault. Bruno talked about Code Kata. There are a whole bunch of techniques, techniques for breaking dependencies. Michael Feathers talks about it in his book on Working Effectively with Legacy Code, I think. There are techniques. Don't be desperate, even if someone tells you no, but in our case, it's not possible to write tests, it's not possible to change. That's not true. So, there you go. And then, it's important to take back control and stop enduring. I no longer want to work in teams where we make excuses to spend our time enduring, complaining, undermining each other, and not finding happiness, or at least pleasure, in working together. So, there you go. Join us, join the Legacy Club, those who want to take back some control over their career and their daily life. At first, we started with the Fight Club image, it was a bit catchy and all, but actually, that's not really what best represents what we've talked to you about. If I had to pick one thing, and you see it even less than Fight Club, it's the Breakfast Club for the... old-timers who have probably already seen this movie. Those who haven't seen it, what is it? It's a movie where teenagers get detention on a Saturday afternoon. They share nothing. There's the rich kid, the rebel, the jock. They all have a bit of archetypes. So at first, they clash quite violently. They're left with the keys to the school or college for the Saturday. And they'll realize through this day that they share more suffering and have more in common than they imagined at the start of the day.
That would resemble more what a Legacy Club is for us. A place where we share experiences, pass on good tips to stop suffering and regain some control over the situations and projects we work on. I think all that's left is to thank you. The Pojo and Clipplose. Thank you very much.
Thank you.