Rinse and Repeat pattern in software architecture and development

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We're continuing our season when we're looking at software architecture patterns and anti-patterns. In this episode, we're going to look at a pattern we're going to call Rinse and Repeat. It's actually a really good follow up from the previous Rosetta Stone, because it is a good example of where this pattern is very applicable. Now this is something that we have stumbled across, although we didn't really call it the Rinse and Repeat. We've seen some similar patterns in the past. If you think of things like factories and some of the factory related patterns, because that's really, it's sort of what Rinse and Repeat is. Instead of the factory, it is the things that are generated by a factory. So let's talk about this a little bit. The idea of the Rinse and Repeat pattern is that we have a process essentially for a solution. That process does need to be customized to some level over and over again. Maybe it's for a specific integration, a specific line of business, maybe even a specific type of transaction. Generally speaking, we have all of the same steps, more or less, and the steps themselves are where there's maybe a little bit of customization. It's not as simple, I guess it could be, but generally speaking, it's not as simple as sending a couple of different parameters in. Because if you can parameterize it, then you just parameterize it and then you have a very general solution. But sometimes what happens with Rinse and Repeat is that the step to go from specific solutions to a general solution is non-trivial. It may be to the point where putting that work in and generalizing that, it's really more work than is worth it. Yeah, we could, but we don't know enough about the various general cases we're going to need to handle. Instead, we sort of push that off. We say, tell you what, let's take what we know will always be the general case, the general solution we can use. And then we're going to have, which is sort of the Rinse, I guess, and then with each new special case, each new case, then we will have these pieces that we will customize for that case. And that would be the repeat side of it. So what we do is we have something where we've built a general solution to some extent, but we know that there is a customization piece to it that we're going to have to do for each repetition. You'll see this a lot in software that is somehow custom to the customer. Where there is, for example, software these days, a lot of times when you set somebody up on a software as a service model, there is some sort of there's a registration to some extent, at least. And then a lot of times there is like an initialization or a build out or some sort of kickoff getting started where you're seeding data in to start it that's specific to this customer. Now it could be as simple as your registration kind of information that is, which can be generalized because it's just, hey, I need your email address, your mailing address, things like that. But when we're looking at rinse and repeat, it's not that simple. It's going to be things like, okay, in order to use this software, you're going to have to actually tell us about maybe how you're going to use it a little bit more about you as a customer. And when you think about things like, let's say, here's an example. Let's say we have something that's essentially a news aggregator. Now what we could do is have a solution where when you come in, we've got whatever it is, hundreds of news sites, and then your aggregation is just working with those. Or what we could have is something where when you get set up, one of the things we do is we work with you to build a custom newsfeed. And we go out and we may have to do, maybe we integrate, and let's say it's like three news sites. So what we do is we go out and we configure your account to actually connect to those three news feeds so that it could be actually very customized. It could be something where you have a login and a password and we have to write a little bit of custom code or do some custom configuration in order to get you set up. Rinse and repeat, I guess, is a good point here is it's not necessarily always code. Sometimes it is just a process that is some sort of a configuration or data entry. So if we control registration, rinse and repeat would be that we go in and we, for every time somebody comes in, we say, oh, hey, here's their key. We turn on their account. Each time that somebody comes in, we go in, we've turned on their account, we go in and we enter in these 10 values that get them started. We send them an email. So it's a process as opposed to, in that case, as opposed to necessarily coding. We're looking at architecture or development. What it typically is, is much like the Rosetta Stone that we talked about would be a good example where rinse and repeat is you've built your central, your core model, your Rosetta Stone piece. And the rinse and repeat is doing that mapping for all of the, however many integrations you need to do to map from that integrations format into your general, your core format that you work with. And that's where this pattern is useful to look at is saying, okay, we don't really, we don't really have the time or it's not worth our effort to build a truly general case. Instead let's take the pieces that are general, the steps that are general, and we will generally solve for those and we'll have those steps. But then we're going to know that every time we do a new run of this, we'd execute these steps again, that there are these steps, maybe a step or steps that we will have to revisit and do some customizations within those steps in order to make this work for the new iteration. Typically it is going to be where you're, it's almost like a templating type of approach where you're saying, okay, I know this chunk of the solution is general, but I do know also I'm going to have to go in and I'm going to have to customize these additional chunks. If you think of like WordPress, that would actually be in itself sort of a rinse and repeat where all of the people that build WordPress sites are given the tools to do the repeat process of it. It sets up a framework or a foundation of an application and says, okay, this is what your web app is, but I need you to go in and provide me some CSS and general formatting information, stuff like that. So if I wanted to, if I wanted to build multiple WordPress sites for people, there is the installation and some things like that, that would always be the same. There's some things that would just, some processes, some steps that would always be the same, even if I'm maybe loading different image files or things like that. But then there's also going to be some things that are customized that I will have to do and I can't really automate from customer or site to site to site. That's sort of where that rinse and repeat comes in is it's the situations where we look at and we say, this really is not automatable. This is not something we can get that general. And so we say, okay, we're not going to, we're not going to struggle with that. We're not going to let that bother us. And instead we're going to define the pieces that are general and we're going to utilize those. And then we're going to find the pieces that are going to need to be customized. And we're just going to make that part of our process and say, hey, when we execute this process, these steps are going to be customized as well. And in architecture and software design, we see this a lot. There's a lot of places where we can see something that is a commonly used solution and we can just make that a part of each of the individual things. For example, from an architecture and actually from a data design point of view, if you think about audit records, things like who, when was this record created as far as like a timestamp, who created it, what user, what user updated it and when was it last updated and maybe even what were the values that were changed? That process of building that audit piece is more, is a good rinse and repeat because what we would have to do, particularly, I guess if we don't use, if we don't track changes, then you can just slap onto every data structure created, created by, updated, updated by. You've got date and user, date and user. You're off and running. But if you have the fields piece or the history, the changes piece, then for each of these new data structures, in order to add that in, you're going to have to also build a little bit of code that goes to, that visits each of the fields or properties of that and then copies those off to some shadow table or something like that. And so you are going to have to customize for each one, but it's a very easy to define and sort of a rote step to take for that repeat part of it. And that's where some of the value of this pattern comes in is that we can have an expensive senior level resource solve and solve the, for the general cases where possible. And instead of them having to try to figure out how to generalize all of those custom bits, you just say, you know what? This custom bit is easy to explain to somebody how to do the customization. And so we're just going to do that so we can take this expensive resource. They solve for the stuff that needs their resources. And then when we get to repeat, since it's very rote and very simple in a sense, it's not a lot to be solved. It can be easily taught and reproduced. Then we can farm that out to lower cost resources and also allows us to scale it up better as well because now we don't have one expensive resource having to do it. We can have a whole bunch of easier to find and cheaper resources doing the repeat portion of this pattern. So while it is useful for us as a, you know, essentially as an individual where we can just say, okay, I can protect the general part of solution. And I know that's always going to, you know, that's going to work. I'm going to run through it over and over and over again. So that's going to be very, it's going to be high quality. It's going to be heavily tested. And then I can limit the changes, the stuff that I have to test again for each customer. But what we can also do is a way to scale or even quickly enhance and extend the system when we use this approach. It's basically saying, hey, we're going to generalize what we can generalize and we'll just go ahead and custom do what we need to custom do. That's all there is to it. Another fairly straightforward and simple pattern, but one that I think is worth bringing up because it's one of those things that I don't know if it always jumps to our mind as fast as it should. And because of its usefulness, it is one that we should keep that error on our quiver in case we need it at any given time. That being said, we're going to wrap this one up. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. There are two things I want to mention to help you get a little further along in your embracing of the content of Develop-a-Noor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Develop-a-Noor site. You can also find it on Amazon, search for Rob Brodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week. And this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at develop-a-noor.com if you would like more information. Now go out there and have yourself a great one.