“The art of destroying software”

Text

[00:00:00.000 – 00:01:02.040] Okay, guys. Let’s get started. What I’m going to be talking about today is a bit different than most of the talks at conferences. How many of you have been to a talk about writing code? How many of you have been to a talk about refactoring code? We’re going to learn most people don’t refactor, they refuctor. I want to talk to you guys about deleting code. How many have been to a talk about deleting code? Apparently there is one. I’ve never seen one before. How many have put through a pull request that removed more code than it put in? And didn’t you feel good? I spent my entire morning today actually building up an entire slide deck. One of the beautiful things about deleting code is it allows you to change your mind. And I actually changed my mind today about using my entire slide deck. I literally built 40 slides and decided I’m not going to use them. So you’re only going to get this one and this one.

[00:01:02.040 – 00:02:04.880] Does anybody know where this comes from? And I really don’t believe many of you are doing octal patches these days. This is actually from a waterfall paper. And the waterfall paper is one of the greatest ironies in our industry. How many have heard of waterfall before? How many have actually read the paper? One hand. Two hands. Oh, sorry. Didn’t see you, Cassia. The waterfall paper is one of the biggest ironies in our industry. So if you go and read the waterfall paper, and I really recommend people to do it. It basically describes what you know as agile throughout the paper. The very first page describes what you currently call waterfall. And this is what happens when you turn from the first page to the second. What he basically states is that in his heart, he truly believes that waterfall is the optimal way of building software. The only problem is it doesn’t actually work.

[00:02:04.880 – 00:03:14.100] There’s another paper that’s like this. And it really gets into what we’re going to be talking about today. How many have heard of the big ball of mud? Yeah, it’s a nasty thing. You don’t want it. How many have actually read the Big Ball of Mud paper? Again, we have like three or four. What’s interesting is the big ball of mud paper basically argues that big ball of mud is inevitable. In fact, it’s optimal. You will be stuck with a big ball of mud due to the economics of software. If you are not ending up with a big ball of mud, perhaps you work in the craftsman industry, you are basically gold plating outhouses. The big ball of mud, what it basically starts talking about, is you need to go through and you need to start making small pockets inside of your ball of mud. You cannot deal with one giant ball of mud. You have to deal with many, many little balls of mud. And this leads you towards the concept of writing code for the purpose of deleting it. The idea is I can walk into any one of these areas of code and I can burn it to the ground when I don’t like it anymore.

[00:03:14.100 – 00:03:48.360] How many have had to put a feature into software before where your current model didn’t quite work well with it? However, that current model is tangled throughout everything and you end up spending two weeks for something that would have been really easy if you could have changed the model. But you can’t. Because you have no idea what this may affect. What if you were to optimize from the very beginning to be able to delete code?

[00:03:48.360 – 00:04:23.360] This is not a new concept. I really learned this lesson when I got into Erlang. When you build a system in Erlang, you conceive the system as a series of very small programs. And you’ll find if you start working in Erlang, you almost never go back and change code. If I have a feature that I need to put into one of these small programs, I normally rewrite the program. This is a wonderful thing to have.

[00:04:23.360 – 00:04:59.200] How many of you are afraid to delete code in your system? Maybe you have some unit tests around it. But unit tests, they only show that the test passed. They don’t show a lack of bugs. How many have had a system that was out there that you actually had people relying on your bugs? Microsoft is wonderful for this. They literally have bugs that are currently backwards compatible from Windows 3. But they can’t get rid of the bug. Because people depend on it.

[00:04:59.200 – 00:05:45.200] What’s interesting for me is when we start getting into Erlang code, it’s completely different than the code you guys are used to working with. And Erlang is becoming the hot new thing. No, I don’t think people will be coding in Erlang. What people are doing is taking the lessons of Erlang and applying it in other places. How many have heard of the newfangled thing called microservices? So, there’s another word for them. They’re also called objects. And if you’re doing proper object oriented programming, when I say proper, I don’t mean C++. I’m looking at going all the way back to small talk. If you look at how people actually coded in small talk, they were basically doing microservices.

[00:05:45.200 – 00:06:08.400] When we start talking about microservices, we are envisioning our system as a series of very small programs. If I have a proper microservice, I’ve got no problem going in and deleting it. It’s very rare that you refactor.

[00:06:08.400 – 00:06:44.720] How many of you refactor today? How many use refactoring tools? So, what’s interesting for me is that most people don’t actually understand what refactoring is. When I refactor something, the very definition of a refactor is I either change my tests or my code. And I only change one out of the two. How many of you have refactored where you’re changing tests and code at the same time? Okay. That’s called a “refucktor”. You are screwing up. So, the whole benefit of refactoring in TDD comes from the idea that one side stays stable. And the other side pivots. Yeah, that’s a really different view of TDD, isn’t it?

[00:06:44.720 – 00:07:20.640] If I, let’s say, refactor my test, I move something into the setup. My code stays stable. So, if the test is green before and it’s green after, I have a set of measurements that I did before and after I made my changes. That’s good. If I refactor my code, my test stays stable. My test ran before, they run after. It’s a measurement. I’m predicting what will happen. Most people aren’t doing this stuff. And the refactoring tools, they even push you to not do this. Most refactoring tools try to get you to change your code and your tests at the same time.

[00:07:20.640 – 00:08:09.040] I think I’m gonna call this Greg’s law. I can actually look at your software and I can know what tools you used. Because your tools actually affect your code. How many of you have worked in a system where F5 step debugging was the only way of fixing problems? It was probably in VB.net. If you go back and watch when that software was being written, guess how the original developers did it. And now there is no other way of dealing with the software. Because that’s the tool they were using and it comes all the way out to the end software. This is common.

[00:08:09.040 – 00:08:42.520] People that are using big IDEs. I’m looking at all of you. I know of exactly three people in the room right now that are using Vim. But if you use a big IDE, that affects the code that you’re building. All of this stuff affects the code that you’re building. If I were to go, for instance, and use a big IDE. And I’m sure most of you have used an IDE at some point. Have you ever tried using that code outside the IDE? It doesn’t work very well.

[00:08:42.520 – 00:08:51.560] It’s the same type of thing with the F5 debugging. Let’s come back to Erlang again.

[00:08:51.560 – 00:09:27.240] So when people are using a tool such as Erlang, they no longer consider their problem to be one big program. They look at it as being many little programs. How many of you have used Linux before? Do you really think that we could have a 12 to 18 month project to rewrite ls? These are not new ideas. The Unix way of doing things is also the microservices way, which is also the Erlang way. How many of you would be afraid to delete all the code for grep and rewrite it from scratch? Okay. To be fair, grep has a lot of options. It’s kind of lost its way.

[00:09:27.240 – 00:09:53.400] These are small programs and we composed them. When we start wanting to talk about building software and optimizing for its delete ability, what we focus on is making small programs.

[00:09:53.400 – 00:10:20.920] You would be amazed at how liberalizing it is to know at any point in time that you can walk into a piece of code and you can delete it. Rewrite it from scratch. And it’s a one or two day problem. It’s not a 12 month rewrite. The ability to rewrite code is extraordinarily valuable. Because what’s going to happen is over time you’re going to get features being brought in. And sometimes a new feature doesn’t fit well with what you were doing before.

[00:10:20.920 – 00:11:36.460] I actually just ran into this probably about two, three weeks ago working on event store. I’ve been working for like the last two or three months and I feel really bad for James Nugent right now because it’s a 10,000 line pull request that he has to review. He’ll enjoy that, I’m sure. But what I’ve been adding is competing consumers. So, basically how RabbitMQ works. And I wanted to add in some new features to competing consumers and I found it did not work well in my model. Like, it just didn’t fit. Now, you can imagine, I delivered the first version to our customers probably about two weeks before, and I decided I was going to rewrite the entire back end. That sounds risky, doesn’t it? Over the course of two days, I rewrote the entire back end of the system. And you know what? When I went to go put my features in, it worked perfectly. And it was beautiful. My guess is it would have taken me two weeks to go back through and to get the code that was there, having the new features inside of it. This is common. If you don’t have the right model and you try to add functionality, you run into issues. You can oftentimes end up spending more effort trying to get your bad model to have the new features than just write a new model from scratch.

[00:11:36.460 – 00:12:19.380] So, the big question is how do we optimize for deleteability? And the way we optimize for deleteability is we start moving away from monoliths. We try to optimize for decoupling. How many of you run coupling analysis on your software? There’s a lot of great tools for doing the sonar and depend. And they give you a lot of valuable information. For me, the right size that I want, and I know you guys all know microservices. How many have heard of definition of microservices, by the way? My big question is, can you separate object, microservice, and actor? I have yet to get a real answer to that question.

[00:12:19.380 – 00:13:22.180] But how do we find the Goldilocks zone when we start talking about a microservice? You don’t want them too big. You don’t want them too small. I’ve heard rules of thumb. You should never have more than 200 lines of code in a microservice. This reminds me in my first job, we actually had a rule that you could not have more than 24 lines in a function. Do you know why? We were actually coding on VT terminals. So, you could not have a function that was bigger than the screen. That’s an absolutely insane rule. Because I can give you really quickly a great system that will break it. What if I were doing an options pricing inside of my microservice? I’ve got one method called price option. Except I want to price it on a video card in CUDA. So, I’ve got, I don’t know, 30,000 lines of code behind the one method that actually runs in the video card and does the options pricing for you. Is that no longer a microservice?

[00:13:22.180 – 00:14:03.140] Finding the Goldilocks zone is really the hard part when we start talking about this. And my rule of thumb is, you should not end up with one of these microservices or we can call them services or we can call them actors or we can call them objects. You should not end up with one of these that’s more than a week’s worth of work to rewrite. What that’s saying is that my personal risk at any point in time that I want to do a full rewrite of this thing is one week. If later I have a better understanding of my problem, it’s a one week rewrite.

[00:14:03.140 – 00:14:51.700] How many of you have worked with a bad model? How many have gone and said it’s a three to six month project to fix it? How do you explain that to the business? So, I need six months’ worth of work that you’re going to see no outside benefit from. We will not add any new features, we will not do anything, but we will lower our technical debt. Because business people certainly understand technical debt. They understand this. It’s a really clear concept for them. I can’t explain that.

[00:14:51.700 – 00:15:33.100] So, my goal is I want to optimize for my deleteability. I want to optimize to rewrite things without a risk greater than one week. And keep in mind this is a rule of thumb. This is not a hard, concrete rule that you should go off and say, but Greg said we should never have functions more than 24 lines. There are times where you’ll end up with a single service that does actually have more than one week’s of work behind it. But in general, you should not find yourself doing this. If you find that you’ve got more than one week’s worth of work, this should be a flag to you. This is a high risk area of code.

[00:15:33.100 – 00:15:56.860] This ability to burn what’s there to the ground and start from scratch is massively valuable. When I start finding that my models are wrong, I delete the code. It is not a huge risk from my perspective.

[00:15:56.860 – 00:16:26.340] It also allows me to do a lot of other interesting things. How many of you have heard of technical debt before? Technical debt is bad, right? I’ve always loved people that said technical debt is bad. How many of you have a mortgage? Do you think there might be a reason why they called it technical debt? Is debt bad? Debt allowed you to buy your house, even though you didn’t actually have all the cash. And you’re going to pay it back over time. Otherwise, you’d still be living in an apartment. Debt is not inherently a bad idea.

[00:16:26.340 – 00:16:46.460] Of course, every once in a while, you might find the 22-year-old that makes 100,000 SEK per year and drives a Ferrari. Yeah, that’s probably not good debt. It’s the same as true with technical debt.

[00:16:46.460 – 00:17:23.340] So, if I go through, I can get something for the debt that I’m taking out. How many of you have done a crap job on something in order to put it to production fast? It happens, right? I need this feature tomorrow. Why? Because if I don’t have this feature tomorrow, we’re going to lose money to a competitor. And it happens. I may put technical debt into the system by doing a completely crap job on it. But I get time to market as a return, as an example.

[00:17:23.340 – 00:18:04.420] Do I care about technical debt as much if I can delete the code? If I’ve made things to the point where we have microservices, and I really hate that term. You guys already know everything about microservices. If you want to learn more about how to get them right, go read some Alan Kay and Carl Hewitt. But if I’ve got a very small microservice, let’s say it’s at maximum one week’s worth of work, how worried about technical debt are you really going to be at this point? If technical debt starts accumulating, delete it.

[00:18:04.420 – 00:18:24.660] I cannot stress enough how important it is to optimize your code for deleting. When people talk with me, they always talk about their 18-month project that they want to get in on. No. Try a one-week project. And if you can’t rewrite this thing in a week, you’ve failed. So, my next question would be how can you make it so you can rewrite the thing in a week?

[00:18:24.660 – 00:19:02.820] This ability to delete code, it removes your fear. How many of you have spent three months trying to estimate an 18-month project just to figure out whether it’s 18 months or 24? Now, I want to just keep your hands up if you’ve ever done that. How many of you actually were correct in your estimate? Within even 50%. It’s waste.

[00:19:02.820 – 00:19:36.900] Any time that we’re doing something that’s a 24-month project, an 18-month project, a 6-month project, it’s waste. Try working on one-week projects. Try working in code that you’ve optimized so you can delete any of the code at any point in time and it’s a one-week project. And you’d be amazed at how good we are at estimating a one-week project compared to how bad we are at an 18-month project. Optimizing your code for deleteability will also improve your velocity.

[00:19:36.900 – 00:20:14.840] When you get into a piece of code, a one-week rewrite is a piece of code that’s basically manageable in your head. How many of you have come into a new system before? Someone else’s code. Or even worse, it was a junior’s code, the junior being you a week ago. And your first five days, you spend reading and trying to understand what’s connected with what and how. Some projects, it might be a month. I’ve worked on projects that it was a year.

[00:20:14.840 – 00:20:40.200] How do you understand a large connected codebase? If I had something that could take you one week to rewrite from scratch, how long would it take you to understand that program? At most one week. By definition. If you can rewrite it in a week, you can understand it in a week. What we’re trying to do is we’re trying to get things to the point that they are small, manageable, and understandable.

[00:20:40.200 – 00:21:12.240] The moment that you start optimizing for the deleting of your code, this is where you end up. And we’re not talking about microservices or SOA. By the way, does anyone here know what “SOA” means in Dutch? I used to have a slide that I would put up. It’s a website. I’ll give you a hint. They don’t test your services. “SOA” means “sexually transmitted disease”. To be fair, once the middleware vendors got a hold of SOA, it’s basically become one.

[00:21:12.240 – 00:21:51.600] But everything that we talk about with SOA, it’s the same thing with microservices, it’s the same thing with objects, it’s the same thing with actors. Okay. Actors had a concurrency model. But what we’re really coming back to is the 1970s. Right? Small, manageable programs that coordinate to get a job done as opposed to writing one big lump of crap. This is what people meant inside of the big ball of mud paper. Try to get small projects inside of a big project. Try to keep things that are manageable.

[00:21:51.600 – 00:22:16.400] Again, my rule of thumb is about one week. If you go into an area of code and you say this is going to take me six months to rewrite, what are the component pieces that would take you one week to rewrite each? And I’m not saying that everyone should go delete all their code all at once. When we start optimizing this way, we end up in a very different place. And it’s a much nicer place.

[00:22:16.400 – 00:22:40.440] By the way, how many of you have really heard of people optimizing as an architectural quality for deleteability? It’s an interesting perspective on the problem. Almost never will you be going through and doing refactoring. Refactoring is also known as delete all the code and start from scratch. When we talk about things like technical debt, don’t worry too much about it because you can delete the code and rewrite it in a week.

[00:22:40.440 – 00:23:27.400] When do you know the most about your project? Is it at the beginning when you’re doing your planning and trying to figure out how to do things? Or is it at the end after you’ve done everything? At any point in time, I’m willing to delete my code and rewrite it from scratch. This is the Unix philosophy. This is the Erlang philosophy. This is microservices. This is SOA. This is actors. The problem is most people are picking up these ideas and they’re never understanding the fact that the goal is to delete your code.

[00:23:27.400 – 00:24:07.240] They pick up microservices where SOA is a concept. And you’ll walk in and find behind a single service they’ve got 17,000 lines of code. How many of you can rewrite 17,000 lines of code in a week? Okay. To be fair, if it’s Java code, we can probably rewrite it in a thousand lines of Clojure. I cannot understand 17,000 lines of code in a week. And it’s important to remember because people will be reading your code. Believe it or not, some poor sucker is going to have to go through your code in the future. Even if that poor sucker is yourself.

[00:24:07.240 – 00:24:41.920] Optimize to keep things small and manageable. In going through and doing this, this will also help us in a lot of other ways. Don’t focus on things in technologies. Don’t focus on things like microservices. This idea is not new. And if you understood the Unix philosophy 30 years ago, you understand microservices today. Try to find yourself in the Goldilocks zone and focus on your rewrite ability.

[00:24:41.920 – 00:25:15.520] The ability to just burn the entire section to the ground and start from scratch. I cannot even explain to you without you guys having actually worked with it before, how liberalizing this is. Your fear goes away. Can you imagine working as a developer and not being afraid? Not having all these tools to try to tell you what is hooked to what and if I rename this database column, what will break in.

[00:25:15.520 – 00:26:01.520] It’s a completely different experience to be in these kinds of systems. Where I can bring in a junior or a new developer and they can be productive their first day. Without having gone through and watched 19 hours of videos explaining how our system actually works. But again, there’s absolutely nothing new here. It’s just a different perspective on the same ideas. Go through and focus on keeping everything as small, independent programs. And I mentioned before that tools will actually focus on your code. Depending on the tool that you use, your output will change.

[00:26:01.520 – 00:26:37.700] Go learn Erlang. I can’t stress it enough. Learn Erlang. If you really want to learn object orientation, go learn Erlang. I know it sounds weird because it’s not an object oriented language. But you will understand much better how objects work when you start looking at them from the perspective of being processes in Erlang. At the same time, it will actually improve your object orientation. And when we talk about these things, nothing here is new.

[00:26:37.700 – 00:27:19.220] By the way, how many of you have heard of an aggregate before from domain driven design? Does that sound familiar to let’s say a small process? Where there’s one process per document in your system? You have consistency inside of it. You have no consistency outside of it. In order to talk to it, you send it messages. Have any of you ever read Alan Kay? How many of you work in an object oriented language now? And you have never read Alan Kay? He had a lot of interesting things to say when he defined the word object orientation.

[00:27:19.220 – 00:27:57.420] In fact, if you go all the way back to his definition of object orientation, an object is a little computer that you send messages to to tell it to do stuff. The beauty of that is it’s a recursive model. If an object is a little computer, I send messages and tell it to do stuff. What’s a big computer? Well, it’s a bigger computer. I send messages to tell it to do stuff and it routes them to little computers inside the big computer. Nothing that we’re talking about here is new. Whether we talk about objects or actors or services or microservices or components, it’s all the same idea. We’re trying to make little programs inside of big programs.

[00:27:57.420 – 00:28:41.540] And there’s a lot of good academic research you can actually go back and read. To be fair, Alan Kay actually said the biggest mistake he made with object orientation was naming it object orientation. He should have called it message orientation. Because people think about it now as the objects, not about the messages that go between them. When you take this fundamental view, this is the exact same thing we talk about inside of Erlang, correct? Except we can replace the word object with process. And, okay, Erlang has a concurrency model. Single thread inside of each one of them. But what we’re getting back to is the same idea that each object or each process in Erlang is a little process. And it’s a process, a program that I send messages to and I tell it to do stuff.

[00:28:41.540 – 00:29:23.940] If you want to hit the Goldilocks zone of these programs, they should be roughly one week to rewrite. And the way we conceptualize our system is a slew of little tiny programs. How many have written a shell script in Linux before? Isn’t it beautiful compared to Windows? Okay, PowerShell is coming along. We compose small programs in order to get behavior out of them. And our focus should be keeping the program small enough that we’re willing to delete them at any point in time.

[00:29:23.940 – 00:30:10.500] And I’ve mentioned it before, but I cannot stress enough how liberalizing it actually is to delete code. You are taking the handcuffs off of yourself. You’re allowing yourself to do things you wouldn’t be able to do otherwise. And you can do this in object-oriented code, you can do this in any type of code that you want. Okay, functional is a little bit different. But at the end of the day, what we’re working with is small programs. And the trick, the one big secret from a Michigan mom that 80% of software developers don’t know, it’s the secret to great consulting, is to never build big programs.

[00:30:10.500 – 00:31:02.060] You can literally make a career as a consultant telling people nothing but that. There’s a lot of consultants that actually do that. Understand nothing but that simple idea. And you can find it historically. It’s happened over and over and over and over again. Why? Because people don’t understand it. The difference between great code and sucky code is the size of the programs. Nothing more.

[00:31:02.060 – 00:31:33.200] When I have 100,000 lines of code, I am shackled to it. I will never understand 100,000 lines of code at the same time. It’s impossible. You cannot keep that much in your head. There will always be subtle details that are happening. And the 3,000 unit tests around it really won’t help you that much. Because you won’t be able to keep in mind all of the things that the code actually does. I need to get things to be smaller.

[00:31:33.200 – 00:32:15.520] There are some other benefits about having very small programs. How many of you have deployed things before? The big bang release is always scary, isn’t it? If you release 100,000 lines of code all at once, are you sure that’s going to work in production? So, I refuse to release more than a few thousand lines of code at a time now. I will never do it. What scares the crap out of me about releasing this size of a program is not that I’m going to go release it and I’m going to run into problems and, you know, it fails. Because what I’m going to do is roll it back at that point. That’s no worries.

[00:32:15.520 – 00:33:08.640] How many have released something and it worked great when you released it? And it died four days later? How do you roll back four days? You guys all write SQL migration scripts. How many of you write a SQL migration script from your new data back to the old schema? The running joke, and I’ve done this with a number of teams, is at this point you either get to wear the cowboy hat or the fireman hat. Come on, you’ve all worked on production issues before. Isn’t it wonderful? You’re knee deep in a production issue. And someone comes in, they want to talk to you about the Christmas party. The idea is if you’re wearing the cowboy hat or the fireman hat, someone will walk over to you and say, oh, okay, I know what you’re doing and walk away. I actually recommend it for teams.

[00:33:08.640 – 00:33:35.120] If I’m releasing 3,000 lines of code to production, can I be reasonably certain that that 3,000 lines of code is going to work? And this will come back to Paul’s talk that he was just having. If I’m only releasing 2,000 lines of code at a time, why don’t I do that 50 times a day? It’s relatively low risk.

[00:33:35.120 – 00:34:11.760] And if I conceptualize my system as being a series of little programs, could I run two programs side by side? Could I have two little computers that I send messages to and tell them to do stuff? And I put half the load on this one. This is called a blue green deploy, isn’t it? We can take all the things we’ve actually learned on these big systems and apply it at very, very small scales. I may want to take 10% of my load and put it on the new program that I put out.

[00:34:11.760 – 00:34:46.360] This is normally how you actually change these kinds of programs. What you do is you go in, you delete all of the code inside of it, you write it from scratch, and you push it to production sitting next to the old program. Once you’re comfortable that your changes have not really broken anything, and maybe you have some tests around it as well, then you delete the old one. It’s the same way you guys deploy software today. There’s literally nothing new in anything that we’re doing.

[00:34:46.360 – 00:35:17.040] Developing these very basic ideas can turn you into a high paid consultant. No, literally what most consultants do is they just explain this one idea over and over and over again. Because teams don’t get it. Teams inherently want to build programs that are too big and too complex. As I’ve always liked to joke, developers have this wonderful habit of solving problems that nobody has. I could do it in a simple way, but if I did the simple way, it’s not up to my level of intellect. So, I need to make it more complicated to make it a problem worthy of me.

[00:35:17.040 – 00:35:38.200] Don’t fall down these traps. Always focus in dealing with your code that you will never have a project that’s longer than one week. You will be able to fail your projects or succeed your projects within one week every time. You are optimizing for your ability to rewrite your system as opposed to planning for change that will happen in your system.

[00:35:38.200 – 00:36:12.560] How many of you can predict what use cases your system will have to do a year from now? Okay. How about next week? Next week, I’m normally pretty good with. I’m not 100%. I’ve actually challenged a lot of teams to do this. Every time that you add an abstraction, I want you to create an options pricing model on that abstraction, and I want you to forecast the probability that someone actually needs the abstraction in the future. And I want you to measure yourself. And then I want to compare you against a dartboard. In other words, a null hypothesis.

[00:36:12.560 – 00:36:55.800] My guess is you will be slightly better, maybe, but you will not be much better than the dartboard. Or we could get the German octopus. Don’t try to plan for future changes. Focus on the ability to completely rewrite everything from scratch when that change actually occurs. And I understand that you’ll be writing a lot of really simple stuff. That’s not a bad thing. Don’t forecast out what changes may happen and try to take your model today to accept those changes in the future. Focus on making little tiny programs, and lots of them, that are very easily rewritable.

[00:36:55.800 – 00:37:38.540] Make the decision at the last responsible moment, as they say in Agile parlance. But, again, these are not new ideas. You can find this going all the way back to the ’70s. And apparently developers are just too dumb to actually realize this thing happening over and over and over again. And we have different ways of explaining the same thing, but almost nobody gets it. How many of you have a program that would take you more than one month to rewrite today? Almost every system I go into has this. Even if you go into good code bases, they’re usually too large.

[00:37:38.540 – 00:38:21.480] Again, the identifying trait of good code is small, isolated programs that can be deleted on the fly. Almost every single aspect of your system will improve if you think about it in this way. Now, with that, I will invite Martin up, who’s going to do the closing. But does anyone have any questions just before we bring him up? I don’t want to hold you guys back from beer. I know about getting between a Swede and their beer.

[00:38:21.480 – 00:39:18.920] So, at any given point in time, I should only have a small amount of state for any given program. And, yes, you will need to have migrations, but your migrations will be much, much smaller. Also on a per program basis, I can start looking at varying methods of storage. One that I like to talk to people a lot is event sourcing. Because if I’m actually event sourcing and I say my state is a first level derivative off my log, then I have a lot less migration problems when I’m dealing with it. There’s no way that you will be able to store state, let’s say, in a read model that you’re coming off of. We can just say it’s even a file. I can’t just say I’m going to change my file without writing some form of migration for it. But ideally, I’m going to keep things small and isolated. So, I’m not saying I migrate my database. This one thing might be talking to one table. If that makes sense.

[00:39:18.920 – 00:40:13.400] Conceptually, yes, but they may come back to the same physical storage. I may have 13 little programs that are all talking back to the same SQL database because I really don’t want to have to manage 13 SQL databases in production. But conceptually, they’re 13 different stores. And they can vary independently of each other. If you go down that road, be very, very careful about integrating the processes through the data. Ideally, each process should have its own data. And if I want access to the data, I talk to the process, I don’t go directly to the data. There are times where you’re going to have to actually integrate through the data for performance reasons. But be very wary about doing that because you’re building in a fairly nasty coupling between things.

[00:40:13.400 – 00:41:02.580] How many of you have integrated through a database before? And people will tell you that it’s awful and you should never, ever do it. But you know what? Sometimes it actually works really well. And it’s a form of integration. Understand that it’s got its own tradeoffs associated with it. You’re putting in fairly nasty coupling. Has anyone ever worked in a company that had a rule that you were not allowed to rename a database column because no one had any idea what it would affect? But it is one form of doing the integration. Ideally, you will do the integration through messaging. But there are times where you actually need to do it through the data itself for performance reasons.

[00:41:02.580 – 00:41:48.180] Schemaless can help. Anything that’s weak schemed is a lot easier to version than things that are strong schemed. Another that I really like to use is what’s known as a hybrid schema. So let’s imagine that I were to use an XSD that defined three or four things that were must understand. But everything else that was there was dynamic. That’s a very common way of dealing with things. Yes. Protobufs, absolutely, it’s something that can be shared. Normally I look at things as protobufs and I consider that to be a library. And yes, libraries get used from many places.

[00:41:48.180 – 00:42:23.020] Many programs link to glibc if we talk about it from a Unix perspective. And going back to your question with weak schema, another way of doing a hybrid schema would be, for instance, if I were to use protobufs and I were to say required on three things and optional for everything else. And that will again help you a lot in terms of your versioning of data over time. Any other questions? Okay. Well, then I will give it to Martin, who will close up the conference. And thank you guys for having me out.