 Should I just kick it off? Get started? Okay. Hi everybody. I'll get us started. So it's only a partial joke about the singing. Is there anybody here that's ever attended any of my training classes before? Yeah? Oh yes, we have somebody in there. Hey Susan. So one thing that I do is, at the beginning of those training classes we set up some rules around how we're gonna run the class. Like for example, everybody helps everybody out, you know that sort of thing. But one of them is, you know we're gonna take breaks and if you're late for a break, you have to sing to the rest of the class. And everybody thinks I'm joking about it. You know they kind of laugh about it a bit. Oh ha ha ha ha ha. Until the first break. And just about 100% of the time somebody comes back a minute late or something like that. And guess what they end up having to do? They have to sing. Yeah, because peer pressure is an amazing thing, isn't it? So, but I promise you I'm not gonna sing to you today because I wouldn't put you through that torture. I promise I wouldn't. So okay, let's get started. Hi everybody, I'm Cheezy. That's kind of my nickname and that's what everybody calls me. And I've been pretty lucky over the last several years. I've had this chance to travel around a lot and work with a lot of really cool teams. Actually I've been doing this for about 14 years now. And I know that's really, really hard to believe because I look like I'm only about 24, right? So I've been doing this since I was 10? Wait a minute, that just doesn't make sense, you know? But what I've been doing is going around and helping people learn agile, learn how to become more agile. And my focus has always been in the technical practices. Yes, I'm a developer, I write code all the time. I'm a tester, I test code all the time. I do all these things, but I've always focused on the technical practices. The last few years, there has been this interesting change which is more and more of my customers have been coming to me and saying, hey, we really want to drive toward continuous delivery. We want continuous delivery. Help us figure that out. And so what I'm gonna talk about today is some of the things that I've seen and some of the things that we've had to do to fix some problems along the way are things we might call anti-patterns. So, and yes, these are some pictures of me as I was traveling around. I worked for a company called Lean Dog, by the way, and these are some pictures that I took of me just having some fun in some of my travels. Pretty good looking, aren't I? Huh? Huh? Yeah, you can shake if you want. Shake your head, yes. Okay, so the first thing I wanna do though is this level set. Before I get into a couple of the anti-patterns, we'll take a minute or so just to talk about that. So often I have a company that says, I want to do continuous delivery, so can you come in and automate our build for us? It's like, wait a minute. Whenever we're talking about continuous delivery, it's not about just automating a build or doing continuous integration or something like this. In fact, my experience is that pretty much everything changes. Not just the way that we write code, the way we deploy code, the way we test, the way, but the company itself changes in order to achieve this. And in fact, I'm just putting out some warnings here that whenever you go down this path, it really is about major, major disruption. It's not just about changing the way that we deploy or the way we build our machines. It's not just about DevOps. It's about the way we lead the company, the way we think about our products, the way we do everything, changes. And yes, there's dangers in that because it's significant upheaval, major disruption, I guess is what I say here. So this is my little warning out to you that going down this path is very, very, very rewarding, but it also is a lot of change in order to do it right, in order to get it out there. In a situation where we maybe just kind of lay over this nice, pretty little DevOps layer and we don't change anything else around it, or yeah, we're gonna hurt ourselves. We're not gonna be successful. So they started thinking about anti-patterns. I started thinking about what really constitutes an anti-pattern? What should we be looking at? How can we, what does it really mean? And I kind of went back to my own career. There was this point in my career where I discovered a specific book. Has anyone heard of this refactoring book by Martin Fowler? Yeah, yeah, it's an excellent book, little old but still unbelievably relevant for what we do. This book to me changed my career, believe it or not. This book to me really started to cause me as a developer to think about what I was doing. I would read a chapter and it would talk about some bad code structure. And it would show you how to improve that or how to make that better. And then I would go back and look at my code and I said, wow, I've got bad code. It sort of opened my eyes. They would say, well, if your code looks like this, you need to refactoring. I'd go look at my code and guess what? It looked like that. And I was like, oh my God, I really need to start changing the way I think about what I'm doing. I need to raise the bar on myself professionally. So one of the ideas that was introduced in this book was this idea of code smells, stinky code. It's exactly what you think. It's sort of this thing that you can look at and it just doesn't pass the smell test, right? So when I started thinking about this, I started thinking about anti-patterns kind of our smelly things, right? It's things that it just doesn't pass the smell test. So in this last picture, that's a picture of me after I accidentally was sprayed by a skunk. I had to take a special bath. I got through it okay. And so I started thinking these teams that I go and work with, what are those big smells? And I came up with an enormous list of them and I said, you know, Nuresh, can I have a 200 hour session? Is that possible? And he was like, no, no, no, no, no, you got it. So I really had to start to narrow down what I talked about. So believe me, I'm only starting to scratch the surface of what I want to talk about. And I also need to clarify that the majority of the clients that I work with are enterprise clients. Does anyone here work in that world? Yeah, a good number of the hands. And there are interesting smelly things that show up at enterprise clients that don't show up elsewhere, okay? And so maybe some of the things I want to talk about, maybe they do or maybe they don't apply to you. We'll see. But here we go. So when I think about an organization, I personally really kind of create these categories, these broad categories. We've got kind of leadership, which is like the people that set up at the Ivory Tower, you know, they're so high up the tower that if you had to go visit them, you know, you had to wear oxygen, you know, those guys, that's kind of the leadership, you know? And then we don't deal with those guys too much, right? Then we have product. These are the people we might, you know, that come to us and say, hey, here's what we want you to build. Here's the idea. So I kind of, there's a lot of different people that kind of fit into that, but I have this category called product. Obviously we've got development and test, which again are key to building the software, operations, DevOps, whatever we want to call it sets there as well. And notice there's like overlap that's occurring here in the middle. For example, product is, well, first of all, development and test are overlapped because more and more, they're becoming one of the same activity, right? And so, and it's hard to make a change in one of those areas without immediately affecting the other area as well. So, and the same with the other. So there's overlap here. Even this is too broad, though, to start to talk about some of the anti-patterns. So I decided, you know, let me limit it even more. So I right away took out leadership because earlier this week we had agile leadership day in this conference. There were already a lot of talks about some of the leadership smells, if you will. Wow, that's interesting. Never mind. I'm not gonna go down that path. And so I said, you know, let's not talk about that. There's plenty of anti-patterns there, but we'll ignore those for right now. And believe it or not, today is called Continuous Delivery and DevOps. And I started looking at all of the talks that are going on here today. And there are a lot of talks that are very, very, very DevOps specific, right? And so I thought, you know, there's gonna be a huge amount of talk around that. So what I decided was, you know, let me, I'm gonna talk a little bit about DevOps as we go through, but I'm not gonna focus on it. And instead, what I really wanna do is focus on these three items here, which is how we're building the software, how we're thinking about the act of actually creating the software itself. Now clearly because of the operations that DevOps touches both of those, we will be getting into that. And we're gonna start, I'm gonna start by turning off my phone because it's going ding. I'll tell you a real quick, funny story. I was speaking at a conference some time ago and I actually had my phone in a pocket, my pocket here. And my phone is set so that every time somebody mentions me in a tweet, it goes ding, right? And it just so happened that the phone was close enough to the microphone that the microphone was picking it up. And so somebody mentioned me and it went ding and it went over the microphone. I was like, oh God. Then it went ding again. And then somebody tweeted, watch what happens when I mention Cheesy's name, ding. And the next thing you know it's going ding, ding, ding, ding, ding, ding. And I'm like, oh, guys stop it. So I learned but it still is going off. Oh well, we're gonna talk about development. We're gonna get started there. We have any developers here? All right, okay. So I'm talking to you for this next section. I'm talking to you. So when we think about the way a lot of development takes place in the enterprise, we're no longer talking about one team frequently. Often we're talking about a lot of teams working together. And so the way that that often takes place is, well, you know, we've got a lot of projects underway. We've got a lot of projects that we wanna do. And so what we'll do is we'll assign this project to this team and this project will go over to this team, you know, and we'll have, you know, eight is we say, you know, we have to kind of manage which projects go out with which releases because we're only releasing every quarter. And so what often happens is we create these code branches and we put this project on this and this one on that and that's how we kind of manage them out and we make that way we can make the decision later. Okay, it looks like this one's just about done. Let's merge it into this one. And we had these roadmaps that kind of lay out. Have you seen that? Are you guys working that way? Yeah, yeah, okay, okay. So, so we've got all this code setting in branches and we make the decision to when to merge, what happens after we merge? What do we have to do? Other than fix the defects of the merge that happened, what do we have to do after we merge all these branches? Anyone know? What's that? We had to build it, but we have to test it again, right? Why? Because we brought a lot of different pieces together that have never been together. And in fact, what we've done is we've brought a lot of different ideas together, right? So we've got all these different teams who maybe haven't spent a lot of time talking to each other throughout and all of a sudden it merges together. And so, this is how things happen a lot. Now, back when I first started developing, we kind of did something like this as well, sort of. But what would happen is we would develop for a very, very long time, sometimes before we would integrate even individual developers code. Now this was a little bit longer than 14 years ago. We won't say how long ago it was. And we would have this thing that we would call Merge Week. Okay? And no matter what time of the year it happened, that was always the time whenever people was like, man, my throat is sore. I don't think I can make it into work today, because we knew it was gonna be hell, right? We knew it was gonna be just absolute horrible situation, right, and nobody wanted to be there and be a part of it. So, and yet, here we are several decades later and that's what we're doing, right? That's what we're doing. We're keeping all this code in separate branches, making decisions, merging it. There's a lot of bad things about this. First of all, how can we say we're doing continuous integration if our code's setting on all these branches? It's really not possible. We're not doing continuous integration at all. Furthermore, this activity, this practice, actually drives our code quality down. Let me tell you why. Because when we're doing this, it is not a good idea to do a lot of refactoring. So I'm the type of developer that after every test, I refactor. And it's nothing for me to see something and say, God, I'm gonna rename this. Oh, this needs to extract out to a class and I'll go through and do a lot of that the way I build code. And yet if I know that it still is going to be weeks or months before my code merges with another team's code that might be doing the same thing, all of a sudden I'm driving a lot of risk into the code base. Why? Because that merge is gonna be really hard. You see, we already had this situation where multiple developers are coding and the code is becoming further and further and the delta is becoming wider. If we add a lot of refactoring to it, that delta accelerates and it drives risk. So I'm telling you that this drives our code quality low. This is the first anti-pattern, our code on the branches. And so one of the very first things I do when I go in and start working with teams is I say, we need to eliminate branches. You got a question? I tell you what, can you hold it till the end? I only have 45 minutes. I got a lot of things to get through. I do have time at the end for questions. Hold it please, I do wanna talk to you. So eliminate branches. So how do you do that? Well, I'm gonna talk about just a few techniques but there are a lot of them and believe me, this is not as difficult as it seems. Everybody's gonna say, oh, this is so complex, it is not. We're able to do this. I've done this repeatedly with different teams. I've done this with products to have 20 or 30 teams on a product. So it is very easy, it's possible to do. That's not easy. It takes discipline but it can be done. So I'm just gonna introduce a very couple of simple ideas. There's this idea called feature toggles. Has anyone heard of that before? Yeah, it basically is, think about it like a gate around a specific piece of code. It's the ability to turn on or off some code. Now clearly if I'm working on some feature that's incomplete, when it goes to production, guess what, it's turned off. So another idea is this idea called branching by abstraction which by the way has nothing to do with branching. Has anyone heard of this technique? So it's all about building up an abstraction layer that has multiple implementations behind it and having that abstraction layer be the single key point to deliver either the old or the new. Kind of like a factory model. If you're familiar with factories, it's the same idea or abstract factory. If you've read the Gang of Four book, you know that stuff. Dark deployments is another idea where we actually deploy the code. It is live, it's in production all the time. It's just that, yeah. If you don't know the secret, super secret URL, you can't hit it but that we can deploy live to production. So the first anti-pattern is code setting in branches. One thing that doing this simple technique does is it allows us to separate out the idea or the concept of deployment from the idea of release. And it really separates that concern in an ideal fashion in my opinion. Deployments now are an IT function. Deploy, deploy, deploy, deploy. Every day, multiple times a day, deploy, deploy. And the idea of a release is something that sets in the hands of a product owner. And if you have a release manager, maybe they might want to be a part of that as well. If you think about it, we deploy, deploy, deploy. And now the product owner says, yeah, you know this feature that we've been working on for the last six days, it looks like it's ready to go. The toggle gets flipped and it's on. So again, that is part of what allows us to constantly, consistently deploy code, even code that's incomplete or in an unfinished state. Okay, so I have another one for developers. So, somebody that I see again and again is developers not really focusing on quality. There's probably a lot of reasons for this. One of them is that in today's world, more and more teams are pressured to get things out under extreme deadlines at all cost. Push this out, go, you gotta hit this deadline. I don't care what it takes. And when you do that, what often happens with so many people who don't have the experience at working fast with different techniques, the code quality goes low. I think that's part of it. But I think there's another part of it. Remember earlier when I said, when I discovered that book, my eyes were open to what I was doing wrong? I think we have a lot of developers, actually a very significant portion of the developers out there whose eyes are still closed. If you think about it, they came from college or university and the very first thing that they saw was bad code. And all the team around them, they're writing bad code. They go to the second team and it's bad code. They go to the second company and they don't know any better. So, it works well, it's just fine until that code goes to the testers. Testers, how many of you have had some code that was passed to you and it took you about 30 seconds to find the first defect? Do we have any testers here? Yep, yep, it's very common. So, of course I tested it, right, right, come on. The second anti-pattern I wanna talk about is a lack of focus on quality. You see, there's this illusion that it takes longer to build quality in. But in fact, my experience is just the opposite. I find that it takes much longer to deliver bad software and then spend lots and lots and lots of time at the end finding defects and fixing them, having these triage meetings where we discuss which defects will we fix and which ones will we defer and pushing dates and pushing expectations out and finally getting something out the door. I find that that takes significantly, significantly longer than building it at a high quality and putting quality front and center from the beginning. And so, again, there's just a couple of practices that I wanna mention. There's many practices out there that we can drive and I'm not dogmatic enough that I say everybody should be doing all of these things. What works for your team might be different than what works for another team. I wanna just mention a few things here that I have found that work across every team. Test driven development. So, no matter how many times I hear people say, well, that's an old practice, that doesn't work. I can tell you that I have throughout my career, since I've started doing this, I haven't found any other practice or technique that I can use that will drive the quality of my code higher and that will make my code such that I can respond to change in the future. Now, there's a lot of folks who believe, well, we can write unit tests after the fact and it's just as good. Writing unit tests after the fact is better than not doing anything but I find that it's first of all, more difficult to do, far more complex to do and most of the benefit that we get, we don't get nearly as much benefit out of it as we do from test driven development. Another practice I wanna throw up here is pair programming, mobbing, whatever you wanna call it. We heard in a rash as keynote a couple of days ago that not everybody is comfortable working in groups and that's true, that's very true. I never go to a team and say, hey, let's pair program, that's something we should do but what I do instead is I start helping people learn by pairing with them and I'm working with developers. I'll go down and say, hey, can I share your keyboard with you and we'll write some code together and then I'll go to another one and we start to learn that that's a great way to do it and then later, eventually, Tom will be working on something complex. I'll say, hey, Sue, can you go over and work with Tom on this together and all of a sudden what happens just by the very nature of talking more and collaborating more, people tend to start pairing. It's not a mandated pair but so somebody who maybe is very uncomfortable with it doesn't participate. On more than one occasion though, I've seen somebody who is very uncomfortable with it and eventually they're the only one not doing it so and in the end they start doing it because peer pressure, I don't know. The last thing I wanna throw out is simple design. Do we have any architects here? Yeah, okay. The vast majority of the architecture that I see these days absolutely sucks. It's horrible, it's hideous. So I have this idea called feeding the beast and that's whenever we're writing code that doesn't satisfy a business need and we have to do that sometimes, right? Most of the time that is satisfying an architectural need and I've gone into teams where they spend 80% of their time feeding the beast and that means only 20% of their time is spent actually driving business value when we're writing code. Oh, by the way, the other, if they can get out on meetings for another 20%, I don't know. Architectures, the best architectures are the ones that handle the things that we know we need to take care of, things like security, things like performance or scalability. There are absolute concerns that we have. Nobody would deny that and nobody would say we shouldn't address these, we have to address these. There's no doubt, but the best architectures are the ones that do this in a simple way and get out of the way. In other words, the goal has to be make the developers as productive as humanly possible. What I see so often is the goal is protect the company from the developers. We've got to go in a separate way. Okay, the next interaction, I think I'm going a little too slow so I'm gonna have to speed it up a bit, sorry about that. I want to talk about the interaction between developers and testers. So a lot of organizations that I go into, well, let me ask a question here real quickly before I go into this. How many of you are working in a place where the developers and testers aren't in the same location? That's fairly common, I see that a lot. How many of you are working in a place where the developers and testers are different time zones or maybe even different continents? Yep, so in my opinion, the most important feedback loop that we have in development is the feedback loop between development and test. Okay, so, but for me, testing's something a little bit different. You're gonna learn that in just a couple of minutes. But for me, development and test are not really two separate things. In fact, this is something that I see more and more in the industry is that, to acknowledge that, often in organizations, those two groups are getting merged into one. It's no longer we build it and then we test it. Instead, it's we build it and that implies that we've tested it. That implies that each step of the way we build the quality in and we validate it. We don't wait until we finish it and then have a two month hardening phase at the end to validate the quality. In fact, we build it and we validate the quality at the same time and we send it to production tonight. We can't do that if we don't have those tight feedback loops. So sit together, work together, same team. Not always can we be in the same location but if we can't be, we need to have high bandwidth communication tools, video, audio, these sort of things to allow us to communicate well. Test and develop at the same time. It's not a situation where we build it and then we test it. In my world, we build automation at the same time that we're building the development and that the developers and testers pair very closely together and that if we have accessibility concerns, we validate the accessibility at the same time that we're building the UI. One in the same notion and so on and so on. We have build pipelines that give us this fast, fast feedback loops. Talk to each other. That's so important and not only is it important to get things done but it's important to build respect and mutual understanding with each other. Testing itself. So Dan North. Have you heard of Dan North before? Anyone? So he's kind of the inventor of BDD, if you haven't heard of him. He gave this amazing keynote talk at Star East last year. It's well worth your time to Google it and to watch it. It was absolutely amazing. I'm giving Dan North a plug here. Somebody tweet that so Dan will like to be happy. So as a part of that talk, what he did was he started talking about some of the different types of testing. By the way, this is only a subset of what he came up with, what you're seeing come up here. Okay, he talked about, and he put them of course in different quadrants and I'm not gonna do that. I'm not gonna do that at all. But what I wanna do though is just point out something here. The items that are green in color are the ones which we write code for. We write code. The ones that are in the orange color, most likely we don't write code for. And so as you can see, the vast majority of the testing practices that we're talking about here, it requires writing code. And in fact, there's another aspect to this as well, which I'm gonna throw out here because when we talk about writing that code, there are other concerns other than just writing the code itself. Things like test data management, things like service virtualization and so on and so on. And things like Datamother for doing fuzzing or some of the property-based testing where we literally run millions of random test cases overnight each night, generating the data that's needed for those and such. That requires coding as well. What's happened is testing has become very technical. It's becoming an engineering discipline these days. Testing is engineering anymore. Again, what I talked about, dev and test organizations merging, that is more and more of a realization of this. We expect our testers to code at the same level as we expect our developers to code. Somebody's gotta do this. And so an anti-pattern that I see is one in which we believe that we can have a lot of manual testers and we can achieve continuous delivery. You cannot. I'm sorry, but unless you want to expose yourself to a lot of risk, you really can't do that. So why? Well, manual testing is slow. It's error prone. It's not consistently repeatable and it's transient and by its very nature. So somebody's gotta do this. What's happening in a lot of organizations I work with is they change their hiring practices and start hiring developers into these test groups. They look across the testers have the right attitude and aptitude to learn this. They help them learn it. Some organizations though they say, forget it, we'll pull this in and in the development space we'll do it. In a continuous delivery world, this is essential though. And so we need to have this focus on automation. So what I see very often is environments where we don't even have a good foundation. And, wow, did this? That's cool, okay. Is anybody here, every time you run your automation, the automation fails because you've got unstable environments? Yeah, a lot of hands going up. What about, you come in in the morning and you look at the test run that happened overnight and you see the 38 failures and you had to spend the first three hours of your day going through those one by one and figuring out if they failed because there was a problem with the app or they failed because somebody messed up, messed with your test data. Yep, so that's kind of the foundation that I'm talking about. We don't have this solid, robust foundation in place then even having all that automation, it's worthless, it doesn't help us. And so some of those foundations, test data management is part of that. So if you don't have the way to set up, I remember Ron Jeffries a long time ago when he started talking about unit testing and TDD, he talked about arrange act assert. Now this came around long before we had given when then which magically kind of maps to those but Ron kept talking about arrange act assert and in that arrange stage for him it was getting that object or the system in a known state so that whenever we do the act it's understood and it's repeatable. And when we start to think about larger tests that arrange act is about setting up the data that I need in one form or another either by staging that data into the system that I'm about ready to access or having some sort of a fake or mock that sets in for that service that I'm calling. And so those have to be in place. Stable environments is the other thing. If our environments are not stable this really is a DevOps focus these days. It's all about now before I run, bring up a new environment. Every environment is the same, it's repeatable. So I've worked at companies where I think I need a new test environment and I have a script on my desktop and I just run it and it comes up. And we need to get to that place where every environment is stable, it's consistent. We're not shocked. And last but not least, I think build pipelines drive a lot of that stability. I'm way behind, sorry, I've only got 13 minutes left. So how many of you have an application that has defects? Come on, every hand, just about every hand. Come on, it would have been funny if I asked how many have an app that has zero defects and by the way that is possible. I see it all the time. So I think having defects in our app is a continuous delivery anti-pattern. And I'll tell you why. Once we start to allow defects to exist in our app and we actually buy expensive applications that are designed only to help us track them, it's an admission that it's okay to have crappy software. It's an admission that it's okay to not have high quality. From my experience, once we start saying that it's okay to have crappy software, guess what happens? We have crappy software. So I started a couple of years ago talking to my development teams right away about this idea that we're not allowed to have defects. And of course, when I say that, they look at me strangely, they've already looked at me strangely, once they learned my name was Cheezy, but I didn't say, oh, that's not possible. But actually it is very, very possible all week. And that doesn't mean that the defect never happens, by the way, but that means that any time a defect occurs, it gets prioritized above everything else that we have. So we're working on a user story right now, a defect is found, that stops, and immediately I address that defect. It doesn't get logged into a system. So it's all about creating this notion that whenever you go to a team, when you ask them how many defects does your system have, there's really only two valid answers. The first answer is zero. Or the second one is, well, we have the one that we just discovered, but if you check back in a couple of hours, we'll have no zero again. And that's the mindset that we need to have. continuous delivery is all about taking a code that we have today and going to production in a few hours. We cannot have defects in our code. We need to focus so highly on quality. Sorry, you guys haven't seen the last couple of transitions, is there a projector coming back on? I'm gonna keep going. The final area I wanna talk about is product. This is kinda funny, too bad you can't see the slides. Oh well, we'll get to it soon enough. So, as we mentioned earlier, product often focuses on projects. We've got all these projects underway and we map these things out to releases and we've built out these nice long 12 month or 18 month roadmaps and we talk about, well this project's gonna map into this release and if you look at my roadmap, it's gonna get delivered next December and we do all this thing. I think that's the worst thing we could possibly ever do for product. It hurts them severely. Okay, so, for me, I think that we need to completely change that whole paradigm and that whole idea of good came up just in time. So let's think about it like this. This is a product donor. It looks like a product donor, doesn't it? It's purple, it means royalty, right? So, and that product donor works with a team and they're working to kind of understand the backlog and prioritize and kind of not been working together to make sure that we're building the right thing and above that product donor is this thing that I like to call the world and in that world, there's a lot of things in there. There's many stakeholders in a lot of companies, a lot of people that think that they know or understand what they want to see go into a product. Obviously, our end users, our customers are out there. We're always trying to know and understand how they're using the product, what they're thinking, what they're saying. You know, there's our competitors. You know, what's our competitor doing? There's nothing more challenging than your competitor comes out with some new feature that's all of a sudden taking market share away from you. Guess what? Priorities change once that starts to happen. If you're building a mobile app, you might have Apple or Google up there. You know, we need to know and understand what Apple's doing so that we can kind of make sure that we take advantage of things that are coming down the pipeline. And so, this whole notion of building out a 12 month or 18 month roadmap is absurd. It is absolutely absurd. And this whole notion of having projects that run for months and months and months and mapping those into releases is absurd if we're thinking of continuous delivery. Instead, the whole idea is about stepping back and experiencing and feeling all the stimuli coming from the world and making micro adjustments. So I'm gonna say that I believe having projects is evil. Go tell your project managers that. Tell them Cheezy said so. Having projects is evil. And furthermore, I think that we instead want to reach this world where, you know, a product owner can have an idea today. They have some idea today. And in tomorrow, our users can experience that idea. They can feel that. They can touch that. They can have. And by the way, we're gonna watch real closely how they interact with that. We might actually go out with two or three different versions and see how they're reacting. 10 more minutes. Okay, great, thank you. Can you sing now? Sure. Okay, next time. And so we watch how our users interact with it and we tweak it the next day. So it's no longer this having these large projects on this huge line of site that lasts for a long period of time. If we're in this continuous delivery world, it's about this ebb and flow of a product instead of a project, projects. It's all about constantly being able to react quickly. Why else would we do continuous delivery if we didn't want to react quickly? If my goal is to get something out there in a month, why would I try to deliver every day? It's all about taking that information that we get and having these nice little tweaks all the way. So if you talk, I wanna just quickly go through some of the antipatterns that I've talked about just to kind of sort of list them out. The first one is code branching and emerging. We said that really sucks. We can't do continuous integration. It defers a lot of the testing that has to happen. It is an antipattern in my opinion. Developers actually teams not focused on quality, not putting quality first. We can't go to production if we're writing crappy software. It's just not possible. We can't deliver every day. Developers and testers not working together. And in fact, I would almost go out on the limb and say, and if we still have developers and testers where we haven't gotten all the way there yet, they need to kind of merge so it's one fluid action. Very little test automation or some of those concerns that we talked about like test data management. If we're not doing those things well, if we don't have code that builds out the data that we need, that arrange stage is not happening. If my environments are not stable, guess what? I have a lot of uncertainty and a lot of risk. And so how can I go to production every day? An environment that it's okay to have defects. The fact that we have a defect tracking tool is an admission that maybe we're not quite ready to go to production yet or today. Last but not least, I think if we're working in projects, for me, this is a huge anti-pattern as well. And interestingly enough, as I've worked with product owners that helped them learn this, they find it so liberating. Because for them, for me to have to plan what I'm gonna do a year from now is horrible. They would love to have the ability to change their mind, the flexibility to change. Unfortunately, so often the budgetary process that existing companies don't allow for that either. I have one final thing I wanna talk about. And I have five minutes. So I'm gonna get this last topic out in two minutes and then we'll have a couple questions. So I didn't talk about this, but I can tell you that usually, we go through significant organizational restructuring whenever we try to take a company down the path to continuous delivery. Let me give you some ideas of what that might look like. So in large companies, we're specialized. We have people that are enterprise data architects that understand database changes. We have people that know how to build shared services and we have middleware people and we have people that specialize in the UI and teams that do that. And so in order to get something delivered to production, it often takes coordination between eight, 10, 12 teams. Who knows what? And some of those shared teams, guess what? It takes weeks sometimes to get time with them. That does not work. So very often what happens, if you're gonna go down this path, be aware that you're gonna restructure your company because if you really have continuous delivery and to have that flexibility to steer and change products like we're talking about is your goal, you cannot do that in an organization where we have these silos, we have these SLAs between groups and we have these handoffs. I mean, you can, but you're gonna hurt yourself really bad. So be prepared to have teams that are comprised of people with different skill sets where we're gonna try to go through as much of a slice of that infrastructure or that application as we possibly can. And be, if you're a developer, be prepared to pair with a lot of people and to learn all those different skills. You should be able to do it. Developers are high paid. We can expect you to learn more than one thing. And that's all I have. Thank you very much. I have some time for some questions. I think there was a, yes. Yes. Okay. Why did you have to create the branch? Okay. Okay, so, okay, so the question is about branching again. They have two different companies that are reusing the system and there's different logic basically on that. And so we've got branches to do that. I can tell you that that's the same argument that I hear for where we've got multiple projects in the same company. And so I can give you an answer to that. I mean, these techniques that we talked about, things like, for example, branching by abstraction is a great technique to allow us to do that. So we don't have to create branches. I can assure you for that. So why don't you see me after the session? I can go into some more details about some specifics. Okay. I think we have time for a couple more questions. Are there any more questions? Okay, one minute, one question. Yes. Yes. Am I talking about full stack developers? Well, that's a fun term. So it depends. Okay, yes. I think developers should, so there are some cases, especially in large companies where that full stack has very, very different technologies. You might have, you know, IMS and kicks transaction setting in the back. There might be some COBOL here or there, that you know, and so on and so on. So, and to say somebody needs to know CICS, they need to know COBOL, they need to know Java, they need to know Java, and all those things, that might be a little difficult. But what we can do is we can build teams where we say, you know, up until we reach that point, you know, our developers should know all of this piece of the stack. And by the way, this team also has a COBOL developer on the team, or a pair of COBOL developers on the team, so that that team can work across that full stack, that that team can deliver into, and if at all possible. But, and also, things like the database changes that we talked about, guess what? When I started my career, all developers designed the database. That was the way it was. I mean, we had this concept of DBA, but it was more of a, when you're done, let me take a look at it, and I'll kind of anoint it for you, or whatever, you know? So, it is very possible, if I need to add a column to a database, it is very possible for a developer to do that, and to script it and to have it done. So, so, full stack, yes, as much as we can, make sure that our team is structured so that we can slice through absolutely as much of that all of it ideally. I think we're out of time. I'm here for the remainder of the day. If you don't mind me talking with my mouth full, I'd love to set with you at lunchtime today, and other than that, you'll find me around today. Thank you so much, everybody.