 you guys are coming, first of all. My name's Taylor Jones, I'm gonna talk about architecture and what's coming next maybe. But we need to kind of view a couple of frames before we figure out exactly what is next. So again, I said my name's Taylor Jones, you can find me on the internet under hi, I'm Taylor Jones. I grew up in this really weird state called Alabama and then I decided to move to an even stranger state called Florida. So I live smack dab in the middle of there in Orlando and love it. On the internet, I write stuff for people like Code Ship, my personal site, hi, I'm Taylor Jones and I just write a bunch of stupid stuff on Twitter if you're interested in that too. This talk is not about Star Trek. So I apologize, I've got a few things in there but we're not gonna really talk about the whole history of the show or any of that kind of stuff so yeah, sorry. Anyways, I work for Isaiah down in Orlando and we do a lot of really, really interesting stuff. For one, we do content marketing. We also do a lot of social media, general data analytics and provide enterprise solutions to marketing systems. All that's to say that we just have a big pile of data and we're trying to organize it and draw conclusions from it. Honestly, we all have these kinds of data. For us, it's social media data. We depend on a lot of external APIs like Facebook, Twitter, Tumblr, any kind of popular social network out there. We're trying to mine metrics and data from it and provide that information to folks who wanna create content. So as far as the tools that we use, we use a lot of Rails and AmberJS. What that means is that our stack is very focused on this convention of our configuration stuff but we have a lot of Java and a good bit of Python in our stacks as well. That being said, the balance of our stack is always changing. We're always trying to look at something new. I think DHH had a wonderful analogy the other day when he was talking about how we kinda drive but we also swerve over every once in a while and try to figure out what's new and why it matters. This talk is mostly about Rails architecture, where it's been and where it's going. We're also talking about technical debt and how architecture can create or relieve it. IZEA has technical debt. Your company also has technical debt and we have to figure out how to address it. I believe architecture is the root of a lot of our technical debt and this seems like a loaded statement or acting like architecture is the problem but what I mostly mean is that it determines the means that our technical debt is piled up and grows. So how exactly does architecture create technical debt? We often come so focused on building features that we forget to clean up our mess and fixing technical debt is also viewed as just not profitable. I mean our stocks aren't gonna go up overnight because we said we're addressing technical debt. People wanna see features shift, they wanna see exciting things, they wanna see whatever's new and hot but how things always been this way. Does modern architecture create more debt? Have we just forgotten something from the old days and did we lose some sort of insight along the way and stop caring about it? So I think it's important to look back in the past and see if we can find something within there. What was early web development like? Well applications were really hard to deploy. Code organization was inconsistent and development was license driven. Environments were also really hard to duplicate and these problems still exist. None of these things are completely solved but if you look at five, 10 years ago they were probably twice as hard as they were today in a lot of instances. So then in this era of the web this thing called Rails appeared and it was really interesting because it employed this idea of convention over configuration. What that simply means is that it eliminates the tedious parts of development like setting up an environment and scaffolding stuff and it allows developers to really focus on the things that matter. This really is an important thing for especially for products that are trying to quickly iterate, trying to quickly develop, trying to develop new features and get stuff out the door. In short, it eliminates a lot of yak shaving in the world. Rails took the web development process and refactored it in my opinion. That doesn't mean that the refactor that it was was automatically good. We can do good refactors but we can also make really bad refactors in our minds. So what kind of refactor do we think Rails is? Well, this is a picture of my cat, so but we do wanna look at how Rails has evolved to kind of understand this because I think there's some really important patterns if you look at just an overarching picture of how the framework has evolved. So if you look at the origin of Rails, we see that it's based on an existing product, right? It's based off the extraction of Basecamp. It has a real world use case by default, right? So DHH could have extracted Rails and gone home and said, you know what? I did it, I put something out there and that's good enough for me because it works and it's a product and we're making money off of it. But what really helped it find its place is making that open source project and opening the commit rights to it and allowing it to grow and for other people to see if it resonated with them. Well, it did. Until probably it started growing a little bit and some folks decided to create a framework known as Merb. Merb was a reaction to a lot of the problems in Rails, right? It's from the Ruby community built this framework and it was like the idea of a cleaner implementation whereas the original Rails was an extraction of a product and an idea. Merb was saying, what if we took these ideas that really resonated with us and we wrote it from a clean, from scratch, from the start without any of the kind of mistakes that we saw maybe being made along the way. And so it focused on speed, scalability, modularity, and API tools. So eventually Merb and Rails decided to merge together. This resulted in Rails 3.0. It was a little bit messy to say the least but I think it was ultimately good for the Ruby community and the Rails community and the Merb community because it united them over a common framework or community because ultimately I think that's what's one of Rails' strongest attributes is a really good community that cares. But as a result, some ideas that were presented both frameworks didn't survive because there were very binary decisions, how to handle maybe certain parts of what was now active record. So post-merger Rails begins to take some of the lessons that maybe it learned from Merb how to be created in general. The fact that we felt like, okay, we're fresh here, the problems with Rails, we're gonna do our own thing and started to implement some of these ideas. So one of the things I think is really interesting in Rails 4, breaking apart the general active libraries and putting them into their own gems, right? So when you bump to new Rails versions, a lot of times you're just bumping those gems which is really cool. And then Rails 5 introduced API mode which is always possible with Rails but it just made it a little bit simpler, right? So after time, architecture begins to become slow and messy and a pain to maintain. What this means is that we have to recognize code smells, bad patterns and other harmful things. This isn't easy at all for us to do, right? Like it's not, you never develop something and think, man, I'm really shipping some awful code and destroying the structure of my application that they know it. It's not until we get down the road that you're looking like, ah, that wasn't a good idea, you know? So a couple years ago, I was doing research for this. This is my first Rails conference actually but I've been kind of long-time listener, first-time caller in a lot of ways and I saw that Robert Martin, who I really admire, keynoted a long time ago. And one of his keynote in 2010 was about the issues that small talk dealt with and what ultimately kind of crushed that community at large. So the thing that he found was that, like one of the many attributes that kind of led to the demise of the small talk community that was really easy to make a mess. This is really true for a lot of things but I think with a language like Ruby and a framework like Rails, we do have to be cognizant of making a mess because a lot of times it can result in some really big performance bottlenecks. So how can we make a mess in Rails? If you haven't made a mess in Rails, I highly recommend it. It's a great learning experience but some examples might be a lack of distribution between model views and controllers. Some people might say models are too fat or controllers are too big or maybe you're doing some crazy stuff on the view layer and there is a misunderstanding of Rails queries, maybe hitting the database too many times. Maybe not understanding what you're doing with Ruby, right? Because Ruby is magic and a lot of times you don't realize that Ruby can be really slow if you don't use it, right? And misunderstanding just common code smells and those things are not unique to Ruby but they nonetheless plague the community. So as Rails grew, it begins to address a lot of the issues that plague the community the most. This involved making the framework more modular, efficient and scalable, right? That's also what I think has led to the success while we have this conference in general is because the community has been able to say, you know what, this is a problem that we're really frustrated with, let's address it. Let's move forward, work together, find the best solution to move into the future. But despite this, Rails is useful as it used to be, right? It used to be the most really, really popular all in one solution but the internet's weird and people write blogs about how it's dead and how it's stupid and how we're all idiots of being here but like, is it as relevant either? Is Rails just done for and we're here? I think that's kind of the answer to that but like, you know, should we just all go home and move to something else? But I do wanna talk about an interesting story that happened with Twitter and their choice to move away from Rails. This is a little bit of a, it's kind of a hard lesson learned when I'm looking back at the history of Rails. So Twitter suddenly became a big deal every night. A lot of people started using it and it became also the poster child of Ruby on Rails in a lot of ways because people started using it really early on, right? But eventually they started to move away from Rails and there was kind of the rumors that the internet, you know, tech crunches right in articles like, oh my gosh, they're moving away from this, it's so crazy. But why did they actually do it, right? It's just a lot of speculation but what's the truth? And so from what I could gather, it came to the idea of when they looked at reinventing search. And when Twitter was rewriting their search engine, they found that they had a lot of frustration with Rails and this had to do a lot with how they handled data, how they queued it up and how they called it from the database. So they're able to make some slight changes on their SQL layer or database layer and maybe move some things around but they ultimately just found that writing in other languages was better for them. So they started to gradually just mantle their Rails stuff and move to something new. So in short, they were breaking down something bigger into unique services that worked together. Sounds really, really familiar if you've studied architecture at all and that comes down to microservices and it is totally the hype train in the Dev community right now and we're gonna have to talk about it because everybody wants to talk about it. And so how have microservices actually benefited companies that are right, they just say, oh man, we switched to microservices, our lives are so much better. How? What's the big deal with it? So I think a great example actually is Netflix. Now Netflix has not really used that much Rails but they were a really big success story and advocate for microservices. So they have a really great architecture in my opinion and if you subscribe to Netflix at all or you see what they do, you can find that they are really good at delivering high quality AC content to you wherever in the world you are. So they had the advantage of using whatever language they want to for these smaller services and they took early bet on it, right? But as their service grew, they were able to really scale it to fit the man in the world. So the question comes though, how do you actually test all the stuff you're building? Because you're building these isolated pieces. So this comes down to Netflix's Simeon army or the testing standards that they created to exercise some aspects of their microservices. The Simeon army created a high stakes for developers as well. So from what I've been researching and understanding about it, they basically have things that will take down production instances of their application if they're not the standard. This is pretty crazy because I don't know about you but I would hate to get a call that I totally am hosing part of Netflix's infrastructure because of something, a typo I made or something weird but they've created this standard that allows them to be able to deliver content despite those downages or despite those hindrances which I think is super cool. The whole takeaway from this is saying that when we change our architectures, our process and our understanding has to change. Meaning that we trade the comfort of what we understand, right? So for me, this doesn't make me a monolith or it might be something else. And we try to say, you know what, microservices or whatever it might be looks a lot happier. It looks like a better life. So I think we should go for it. But every architecture is a brave new world in many ways. It can be dangerous. It can be dicey. If we do it wrong, we could seriously hurt our businesses, lose a lot of developers and really just have a horrible time with it. So how does it success stories though, right? With Netflix or maybe Twitter funding success and moving is something different. How does that work for Rails? So I wanna talk about what it means to actually design certain patterns in Rails. So for one, we have monolithic design and monolithic design, if you don't know, if you haven't ever reasoned it out or looked into it, it's basically this. You have these connected pieces all within some encompassing environment and they can share data with each other. They have pretty good knowledge of what each other does, right? If you think about Rails, you could technically call stuff from the view layer and understand the controller and make database pings and all that kind of stuff. They all, the cool part about Rails, right, is that you're able to pass data incredibly easy. You don't have to write an interface or anything like that to the properly scaffold and get data going throughout your application. So the deal with monoliths for Rails is I think it's always skewed historically towards that tendency. And that's been a really good strength of it, especially when we talk about, remember the history of early on where everything was really hard to configure, everything was license-driven, environments were a pain to set up and import across. But it has been a subject of a lot of hate mail, right? Especially in the modern day, because everybody's saying, well, I use a monolith and it's awesome and I think my research is stupid and the people in my research say, well, I think you're really stupid and I'm gonna write a medium post about it. But one of those kind of big pieces at Ruffleshoe Feathers, DHH, wrote something called the majestic monolith. And it's basically saying, basecamp does this, we really like it a lot. We don't think that Microsoft's people are chumps, but don't come at us when we say we use a monolith. And that was it, but it turned into a whole firestorm for a few days and people got mad and said, everybody was an idiot and is stupid. But the point of monoliths though is that they're rooted in uniformity and they're also rooted in very tight coupling. So Isaiah had monolith architecture to start off with like maybe a lot of apps. What this means for us is that we learned the hard way of how to process a lot of our data. So as I mentioned earlier, we have a lot of data incoming and a growing amount of it, right? With every user that connects to our service or every business thing that we do, we were tracking these metrics and analyzing them, seeing how well a lot of our content does. And we realized a greater need for processing all this data, right? And you can use great tools like Sidekick and we certainly do and love it and they're great solutions for dealing with that kind of stuff. But we said, what would happen if we started dabbling in some AWS, right? What if we started maybe riding a few Lambdas and trying that? And so soon enough, we found ourselves kind of going this weird journey where we're heading towards microservice all of a sudden. And this is kind of where the whole idea came into my head and what I've experienced and kind of been able to watch that the past couple of, past year or so. So if we remember our monolith, microservices are kind of like this in a simplified way. They're very independent pieces that are a little bit cleaner looking. They're naturally more aesthetic to the eye. You're like, of course I'd want the neat things as opposed to the big blob that looks like some kind of amoeba or something like that. And I think a lot of folks kind of wonder how Rails fits in that microservice ecosystem. So I think the most popular usage for Rails is with the API. I think that there are a lot of ways that you can use other aspects of Rails, but if you're talking about, if you tell me, hey, you know what, I wanna do microservices with Rails right now, I'd say build API on Rails. It's a great tool to do so. So how we handle that is we use our, still our big monolith-like Rails app and we make calls to AWS in little services that we build or any other kind of service we might build. We could go roll something up completely in Java. We don't have to ride a Lambda to do everything or anything like that. So the advantage is we can have developers that are focused on looking at maybe some more intense data problems. We've hired a couple of data science folks, a couple of analytics developers and they've been really instrumental in helping us process and queue up all this data that we have. So I think some tips though, if you're gonna do it, use a stable language when you're taking a big bet on something, right? For example, I love Rust. I think it's a great language, but I would not rat my entire metric service in Rust right now. I think what Yehuda and Godfrey and all folks at Skylight are doing with Helix mean that they can run Rust at a lower level on their Ruby stuff is a really great example because they're able to take a risk on a newer language that's really proven to be awesome, but they're able to take a small risk and capitalize upon that if they see success in return. So if they found that Helix didn't work, they would just go back to what they were doing before as opposed to putting their business on a limb because they didn't wanna try something new. And so luckily there's not any disaster stories to tell from those kind of stuff, but I feel like it's important to put that out there. So microservices are rooted in modularity and they're also rooted in loose coupling. So when we have, we compare the ideas of microservices and monoliths and they seem pretty night and day, right? But the more I've kind of researched and looked at our stuff and looked at other people's stuff, I've kind of figured out a lot of people live in between these two ideas, right? Like us, we have a big Rails app, but we also utilize microservices and we're heading towards that journey and we feel like we're gonna make it to eventually just having equal pieces, but even all your microservices probably aren't gonna be the same size, right? So there's this idea of microservice ecosystems that looks like this. So we got our monolith. We have our microservices. And this is what I think a microservice ecosystem looks like. And it might be, Taylor, you just add a square behind it. This is stupid, like, you know, but the point I see with it is that we're able, we have very neat pieces, but they're all controlled by some kind of higher being in a way. And these ecosystems root in modularity, right? They have replaceable pieces, but they are also a little bit tighter coupled, meaning that they have a bit more knowledge of each other than maybe the standard microservices might have, right? So when you write a microservice, you have to write an interface to understand that kind of stuff. The point I'm getting at is that most of our stuff exists in the space where we have smaller services, but they have a lot more knowledge almost and they need to know about other services. And the more I thought about it, I think Docker was a great example. So with Docker, you can create these small containers, right? You can put your database in Docker. You can put your Rails app in Docker. You can put your other front-end services in Docker. But then you're gonna end up using a tool like Compose, for example, to control and to really organize all these pieces. And so Compose is the thing that has the knowledge of all that, these smaller units. Amazon Web Services is also a great example where you can choose a variety of Amazon services and pay them an infinite amount of money to use them all. But the beauty of AWS, to me, and what I found that we love at IZEA is that we're able to properly just use whatever we want and it really works for what we have and it kind of automatically configures and scales itself depending on what we use. But more so, the point that I saw, even from the vanilla use case, is that Rails is very much this kind of thing. In many ways, I believe Rails is a microservice ecosystem. And that might be controversial. Sorry. You know, this might be controversial, but I think that we have these small modular pieces, right? We've been working towards making parts of the Rails ecosystem independent so that we can easily replace that with. So we can choose what kind of server we want in Rails. So you can oftentimes, you can insert React or Ember or Angular, all these things into our services. And so we have this a bit tighter coupling as a consequence of that, but we're able to use Rails and customize it to our means and we can really pair it up and pair it down. And I think that's a result of a lot of the development that we've seen in the Rails history of things. So you might say, okay, I see what you mean, like this is great, like I get that we're a microservice ecosystem and we used to be monoliths and we're not seeing microservice. Well, I wanna do it, man. I don't care what you have to say, like just tell me how to do it. And after all, one architecture is not fit all Rails apps. And I think that was the point of a lot of the discourse that goes on in the internet where we yell at each other about whether who's better. So let's say you won out, how do you get out? This is the part I wanna talk about how we switch architecture without crushing our hopes and dreams. And I think the first step that you have to do when you look at switching to something new is you have to kill the hype. Forget about your love for Rails, forget about your love or hate for Java or anything else out there. If you're gonna evaluate what you're pairing down or what you're switching to, you have to understand that your history sometimes doesn't matter in that sense or your love or hate. So the important notes, there's a difference between implementing something in a project that's smaller and putting in a production code. Please realize that was kind of a note I said on Rust, no languages earlier that we don't want to take really big risk because that's a bad idea. But I think it's important to be excited by new things but also be skeptical. You have to reset your bias on things. Things have changed in the development world. But also what you're doing is working just fine. Every method has a balance or kind of zen for each group of people. And you have to think about what type of architecture also supports your team's size and skill sets. If you're a small startup with like three developers, don't necessarily go after building 20 microservices in different languages because that's gonna be really hard to maintain. I think secondly, it's important to find your pacing. And what I've seen is that we talk a lot about DevOps. We say that, oh man, we're gonna go to the DevOps conference. We've hired a DevOps developer. We're all DevOps crazy over here at DevOps Incorporated. But you have to realize that when you change your architecture, your employment process, your development process, your scrum process, whatever you have, it's completely getting reset for the new context you're going after. And that's what we've realized at IZEA is that we have a lot of developers doing different things but we have to realize that the balance that our developers and what languages they specialize in has to coordinate with the ability and their knowledge of deploying. We have to go from having just like, okay, here DevOps guide, deploy the code, we're gonna keep developing to training developers to have responsibility of the code they write. So finally, I believe that knowledge is power. And this is where I'm gonna veer into this whole idea that we're not all on the same page in programming. That's always been that way, even when programmers were some high-class people that were all went to college and had master's degrees and that could out-science and out-math everybody in the world. We often only let people that we consider professionals discuss design in a pre-architecture. It's almost like this kind of very holy ritual that we have. But what happens when these people retire and move on? We don't wanna focus in front load all our knowledge or all our architecture thoughts or anything like that in the hands of a few people. We wanna train the next generation of developers to really learn how to design well. So I think it's important to realize that we all come from different places and backgrounds. I've loved this conference because I've met more coding bootcamp people than I ever have. I work with a lot of them at IZEA and it's a great blessing. But it's really cool to see one that folks that are either teaching themselves or taking an initiative to do these bootcamps are coming and saying like, I'm not only learning this stuff, I'm wanting to get involved. I think it's important to embrace your history and implement in your work. Never feel ashamed because of what you do or where you're from. Don't ever let anybody think and tell you that because you didn't go to college, you didn't do whatever that you're not a good developer that you don't know anything because the reality is I did the whole college thing. I did the kind of higher level education. I learned a lot and I loved it. It was great. But I do think that I love hearing the perspective of people who are self-taught or with bootcamps because oftentimes they're seeing stuff that I don't see. And I think that's awesome. So how do you kind of help share that knowledge in a team environment? And I think that I came up with kind of six steps that I saw that would be a really good start for trying to figure out how to design with the team and to share that knowledge. One being that you don't want to have too many cooks in the kitchen, right? You don't want to have a design by committee necessarily but you want to say, hey, let's get like kind of three of our top developers together and let's kind of butt head to see if we can come up with this design. Then you're going to bring this preferred design to a small but diverse team, meaning diversity experience and backgrounds. So you want to kind of hear from all levels, try to workshop it as diversely as possible. Take that feedback, go back with your core team design and then bring that whole design to your engineering team. Let them see that and learn from it. Whether they want to or care about it or not, it's not your problem. Just put it in front of them. Charati gets some feedback, workshop it maybe once more and then bring it back and say, hey guys, this is what we're doing. We've all agreed on this but we made some executive decisions because we are at our place where we're supposed to be because of a reason and this is what we're doing. So this is a little chart of how that might work, right? You have a small core team, you got the little workshop team and you got the whole engineering team just to visualize that. Few kind of thought-leadery devices or like absolute things here, right? Effective software teams teach each other in my opinion. Effective software developers have a desire to learn. You don't always have these two syncing up with each other, right? I've been part of companies that have a lot of guys or girls that can teach well but they can't, nobody wants to learn or maybe have a lot of people that want to learn but nobody wants to teach. Everybody wants to kind of just really shut them out and I think there's been some great talks this weekend on that sort of subjects and I refer to other people. I think Marcus Keena this morning was awesome a variety of other folks have spoken about some really great stuff as far as how do we sync on the same page or what can we do? This disconnect is creating developers a lot of times who are comfortable with being in their own environment. So what I mean by that is that we have a lot of folks that are really good at being working at company X but aren't necessarily concerned about growing and I think it's really important that we look at ways that we can help teach people and help them grow and not be worried about what that means for us or that they leave us or they go to some bigger place. Like we should be focused on making good software and teaching people and loving people well. So here we're gonna go into the kind of wrap up and maybe try to stream together a lot of things that we've done here. Architecture in many ways is a house. Debt piles up in different places. A good example I think of this is Spaceship Earth. I love going to Disney. I think it's awesome. Spaceship Earth if you've never been on it it's just a big old globe. It has a ride. It goes all the way up through it. It's super cool. The problem is that it's a unique thing. It's this own piece of architecture. There's another building at Disney and we compare the two, right? We look at this and we say, okay, maybe like dust and clutter and all the yucky stuff that we wanna clean is gonna collect definitely in this place and it's gonna collect in this place right here. And that's okay. Architecture can sometimes be a scape hatch for us to escape debt. In Twitter's example, that's why I brought it up. We saw that they said, you know what? We've kinda painted ourselves into a corner because we have this big user growth and we have all these problems that we're trying to rewrite search and make it better. But ultimately it's just easier for us to ditch rails and switch to something else. Ultimately we need to learn how to clean our house and maintain our house. Maybe it's expensive. It doesn't mean that you should ever not move. It doesn't mean that you should always fight the battle and go down swinging. Like you need to learn how to clean up after yourselves, guys, singles. Like it's important to learn how to confront technical debt. Find a place in your process that allows for addressing debt while pushing forward features. You're never gonna have a time to stop development completely and work on technical debt. I'm sorry to break it to you. I'm slowly coming to realities with that, it's a grip to that reality, but we have to find a way to do this in the way that we deliver features. It might take longer, but also it's gonna mean that you're delivering cleaner and better features to your customers. I really loved it when I have written stuff and I've been cognizant of the mess I'm making in the very few times it happens. And, you know, being proud of that because one, I saw the problem, two, I'm not getting yelled at, you know, a couple of weeks down the line because something blew up and a person's really mad. So it's a really great incentive for me to write good clean code. Architecture should feel comfortable. Ultimately, it's after developer happiness. People should not switch to microservices because they wanna be cool or they shouldn't feel like they can't switch because they don't wanna follow a trend. They should be after what makes them happy and what makes you feel effective as a developer. This is really prevalent in the Ruby community, right? The idea of Ruby is bent on developer happiness. Rails is bent on developer happiness. It's there and we're using these tools because we feel like they help us not only become better software developers or writers or anything like that, but because they make us happy and they make work feel less like work. That makes sense. So what's coming for us next, right? We're talking about the next generation. So okay, we've rolled through the past and rolled through the present. We've kind of talked about the current debate that's raging on, but what's gonna be next? I don't have the slightest idea. So I'm sorry if you can just talk to me on the answer. I don't know what's coming next. I can't predict the future. But what I can say is that we look at these small pieces of history, right? Within the history of Rails, with the history of architecture, we've kind of seen this back and forth between monolith and microservices and we're seeing the pendulum swing over to more modular microservice like code. That's not to say that things won't become more monolithic or anything like that. Maybe there's this idea of web assembly coming along that is gonna completely ruin our jobs and make us all code C++ in the browser again. I don't know and that's okay because I really like being the developer right now. I think it's a lot of fun. I'm really excited to learn about the past and how we got there and being thankful that I'm not having to do a lot of stuff that people used to do or solve problems that people have already solved. But I want to be excited about the future and maybe we're gonna be writing blog posts to each other about how we don't use servers anymore and we're amazing and you suck. I don't know. But that's okay. I think we're ready for whatever's next. So that's my talk. Thank you guys for coming along. We've got about five minutes for questions if they want us to talk. If not, we can talk later. But yeah. Like how do I clean up technical debt while working on features? Well, I think that's kind of hard, right? And it comes down to changing the environment at where you work. So whether you work in a company or where you work for yourself as a consultant. A good example I think of that whether you might roll your eyes and not about it is TDD. So we look at TDD and we say we write tests, we write code and then we refactor. That's an important pillar TDD I think it's ever looked. And so I think that the cleaning up the technical debt should come up in the refactor part honestly with TDD. Not everybody uses TDD and everybody's got a hot opinion about it but whatever your TDD is, I think it's important. I think it requires having a structured process mainly that you're looking and you're saying, all right, we're designing code, we're writing code and then we're cleaning up code and whether that means that like if you're doing pretty well in technical debt and you say, okay, well, you know, we'll only take maybe, you know, two hours out of every cycle to clean up stuff. But maybe when you're saying like, okay, your Twitter and your application is scaled beyond growth and everything seems like a garbage fire. Like you might say, okay, we're gonna try to just fight this as much as it can expand our time. So yeah, realizing from a leadership level that like, hey, we need to do this and that kind of sucks, right? Because we can't, some of us aren't leaders or some of us don't have the ability to change culture and it's kind of like, but I think there's even time within your own specific cycles that you can say, you know what, like I'm gonna try to develop this feature as fast as possible, but also clean it up, make it better. So cool. Well, come talk to me afterwards if you have any more questions, but thank you guys.