The solid principles that we are going to discuss use this technique to organize the source code dependencies in our system so that change does not propagate. And with that, perhaps it's a good time to break for a couple of questions. If you have questions, I will be happy to answer them. And it looks like there are some in the chat. So I will read them and I will answer a few of them. Let's see. One question is, how do I convince my boss that I need more time? My boss doesn't enforce the team to make automated tests. What should I do? Now, here's the question that everyone always asks. How do I get my boss to give me more time? You don't get your boss to give you more time. You tell your boss how much time something is going to take. And you are very careful about the way you tell your boss how much time something is going to take, you do not say to your boss, I think it's going to take me four days. You do not say that. You do not say, oh, I think it'll take me 12 days. You don't say that. What you tell your boss is this. If everything goes right, which it never does, by the way, but if everything goes right, there is a 5% chance that I might be done in five days. If everything goes the way it usually goes, then there is a 50% chance that I will be done in 12 days. And if everything goes wrong, which it sometimes does, there is a 95% chance that it will take me 30 days. Those three numbers are the important set of numbers to give your boss and to stick by those numbers originally. You say to your boss, look, I don't know how long this is going to take, but there is a probability distribution here. There's a 5% chance it'll take five days. There's a 20% chance it'll take me 12, a 50% chance it'll take me 12 days. And there's a 95% chance that it might take as long as 30 days. Your boss is not going to like that, but that's his problem or her problem. It's not your problem. What you have done is tell the truth. When you say, I think it's going to take me 12 days, you are lying, because you don't think that. You don't know how long it's going to take you. You must give a probability distribution. Your boss is going to be angry about this, not going to like it at all. They're going to demand some kind of some deadline, and you're going to have to say, some kind of some deadline and you're going to have to say, I can't promise that. I've told you what I can do. Now, at every possible moment, you refine that, right? Every day you come back and say, yeah, I've been working on this and it looks like it's going a little better than I thought. And maybe I can narrow that probability distribution a little bit. Or you might come back with worse news. You might come back and say, yeah, I've been working on this a lot. Boy, it's a lot more complicated than I thought. I need to widen that probability distribution. That is how you deal with your managers. This is not going to make them smile. That's not your job. Your job is to tell the truth. Their job is to manage uncertainty. That's what managers do. That's why they're called managers. They have to manage the uncertainty that you provide to them. And I know you think, well, I'll be fired. Well, if they're going to fire you for doing your job, then you probably need to find another job. Another question here is, when is the right time to say enough and create the software from scratch? Boy, oh boy, that's a difficult question. And here's my first answer to that. Don't ever do this. Now, that's not exactly true. There are times when it is appropriate to just say, okay, I've had enough. I've got to throw it away and start over. However, those times are very rare, and they are for small things. Something that maybe took you a month to do, you can probably throw it away and do it again. It'll take you another month. And is it going to be better? Well, you kind of hope it'll be better, but there's no guarantee it'll be better. But for anything larger than that, it is very, very dangerous to throw it all away and start over. Everybody wants to do it. Everybody says, oh, if only we could start over, everything would be so much better. No, it won't. Because you really haven't learned that much. And even if you have learned that much, all the pressure is still going to be on you to make the same kind of messes you made before. If you don't address the thing that makes you make messes, you will still make those messes. No, no, no. The way to proceed with a messy pile of software is to clean it. And you cannot start a project to clean it. Do not go to your boss and say, we need three months to clean this software. No, it'll take you much longer than three months. And you will make a bigger mess because you put a deadline on it. And you will leave the system in a much worse state. The trick here is to change attitude. Your attitude, everybody else's attitude. And follow the following guideline. It's called the Boy Scout Principle. Check the code in cleaner than you checked it out every single time. You always make the code a little bit better every time you check it in. You never make it worse. And every time you check it in, you do some random act of kindness to make it a little bit better. And over time, if everybody does that, over time, the system will get better and better, perhaps even to the point that you can start adding tests. And if you can add tests, then it becomes easier and easier to make it better and better. Another question. Do you think that fragility can be fought with a good suite of tests? Yes and no. A suite of tests is not an immediate answer to fragility. A suite of tests is not an immediate answer to fragility, but a good suite of tests is a way to help you make the design changes that will gradually eliminate fragility. A suite of tests gives you the confidence to improve the code. Why does code rot? Code rots because you're afraid to clean it. And you're afraid to clean it because you don't know if you're going to break it or not. If, however, you have a suite of tests that you trust, you are not going to be afraid to clean it. You will clean it. You will make the code better with every check-in, and that will make the design better and better, and it will reduce fragility to the point where fragility virtually disappears. Another question here is, what is the difference between design and architecture? There's no good way to specify the difference between design and architecture. Design and architecture are two ends of the same thing. And in fact, I will add programming to that as well. Programming, design, and architecture are a continuum. They are all part of the same thing, which is software development. As you move upwards through this continuum, you go from coding to design to architecture, but there's no line that you can draw that says below the line it's design and above the line it's architecture. As you get higher and higher, things get more architectural and less designy, and as you go down, things get more code-like and less designy. And in the middle, it's kind of more designy than code and more designy than architecture. But there is no line that you can draw anywhere in that continuum.