Podcast Episode 191: Episode 164 : Mastering Best Practices: Navigating Core Block Cloning

Description

Join the core team as they talk through the challenges of cloning core blocks in our new Best Practices series. Discover the latest updates and catch insights from the CITN conference in this tech-packed episode.Show Notes:Version Releases: https://www.rockrms.com/releasenotesBest Practices Series: https://community.rockrms.com/connect/cloning-blocks-best-practices-seriesRX24 Tickets: https://rx.rockrms.com/Rock PartnersWe are thankful for our Rock Partners and their support of the Rock Community. Visit their websites through the link above to learn how they can help your ministry and confirm that those you work with are as invested in the success of Rock as you are!

Transcribed Content

This episode of Rockcast is brought to you by Rock partner Triumph Tech, a full service specialist partner. Rock partners provide crucial support for Spark Development Network and important services for the Rock community. Connect with Triumph Tech today at rockrms.com/partners. Welcome to this edition of Rockcast, the podcast that explores the intersection of technology, ministry, and community with ROCCRMS. I'm Emily Forman, and joining me today are Jon Edmiston and Nick Airdo. Let's talk Rock. Nick, start us off. Let's talk about versions. Yes. So we are at the finishing stage of 15.3 beta. So at the time of this release, I don't know, maybe it will be into release 15.3. And there's about 21 bug fixes in there. A lot of them are just for the event registration. I thought we were going to start 16.1 alpha testing, but because of the next topic, which I'm going to talk about after this, we delayed sixteen:one. So sixteen:one is gonna start alpha probably on a Monday next week. It's kind of one of those works of art though. You're just , when are you done? It's , sometimes you just have to say, no, we're gonna have to be done. There's still more things we want to put into it. Exactly. A lot of At the latest count as of just now, now there's 117 closed issues in 16.1. One hundred and 17. Wow. And we're down in the forties. Really? Open issues. Yeah. For a ten year old product. That's incredibly impressive. A backlog. That is very impressive. So yeah, we wanted to get it down into the twenties and thirties though now. So that's going to be the Christmas goal. That'll be up next. So Don't open issues. Just kidding. Please don't. Unless you have to. It's hard to keep going down when they keep going back up, no, no, no. Please, if you have an issue, turn it in. And we'll be responsive. For sure. And so we delayed 16.1 Alpha testing because I got to go to the church IT network, also called the CITN. So the CITN is kind of where we got a little bit of a start about nine and a half years ago with the Rock one point zero beta launch party. I think it was in not Peoria, Arizona, but Peoria, Illinois. So that was cool to be there and see all of our community that was at the Church IT network. What other notable things? There was a panel of CHMS, as it's called in that group. So we got to participate on that panel and got to provide some answers to questions about the industry as we saw it. So I don't know if it's recorded, but you can feel free to track that down somewhere and listen to it. I'm not going to try and summarize it. Yeah, thought you did a great job on the panel. I got a bootleg copy of the audio. I thought it was funny though, because someone said, Well, we don't to call it CHMS. I'm , Well, you're a little slow to the game. Started by not calling it CHMS. So I thought those were kind of funny. Yeah, it was fun. It was fun to be there. And yeah, thanks again for the invites, everyone. Definitely, we've got a great community. All right, we have a new topic. We have a new topic, and this is gonna be a series of topics, something that we've been kind of thinking about and planning for quite a while. And this is gonna be what's best practice within rocks. We wanna have this as a continuing segment. It may not be every podcast, but we want to definitely in 2024, make it a serious part of the podcasting is talking about the right ways to do things and some wrong ways to do things. So we're gonna kick it off today with our first one because we're gonna get an early start to this. And it has to do around core blocks and specifically about forking or cloning core blocks and why that is not a best practice. So the first one is what not to do. All right. And we'll have some what to do's, obviously too. But as we go through this series, each topic will be very helpful, I think, but some are gonna be more helpful than others. Some of them gonna be more highly recommended than others, and some of them are gonna be more highly don't do this than others. And I think we're starting with a very important one. This is a highly, please don't do this. And it's not for us, it's for you. So let's kick it off. Again, topic, cloning core blocks. What's wrong with that? Let's first start with that and I'll kick it off. Here's the first thing. You have to support this forever. So when you take a block and you copy it, so you take the core block and you just literally copy paste it, give it a new file name, it's on your server. You now basically own that block forever. It's something you have to think about forever. And you're gonna be carrying that baggage forever, which kind of leads us to the next point. Yeah, what you have to do before you update your Rock is you really need to test it. So you need a staging system to set up and test that block to make sure it still works with that next version of Rock that you want to deploy to your production system. That's a lot of extra stuff. Right. And do you think often that is done before you do the update? No, no, no, no. People don't do that. Yeah. And it's not because, know, being lazy or something, you just forget about it. , most of us don't have the processes in place to rethink all that or the environment sometimes. And some people are just crossing their fingers hoping that it's not gonna break. Yeah. And sometimes there isn't a comprehensive list of all the blocks that have been cloned. Right. Right. And sometimes maybe you didn't do it too. Maybe the person before at the church did it, or maybe a partner did it. Maybe the partner's not even there. So you own it forever, but you didn't even know it. Which brings us to point three, I think really timely, which is it causes a future investment in the future. you will have to clean up that mess. whether it or not, you have to, because then we're gonna talk about why those reasons are coming up, but it's a huge investment. And I think one of the things that breaks my heart most working in Rock is hearing stories this, where a church comes to us years later and is , -oh, look at this, we have to clean this up. And how do we clean this up? And who do we go to to clean this up? And then you realize the funding that's gonna have to go for that church just to clean it up. And that's not a good use of their funds. And it's not a good stewardship to do that. So often maybe the church didn't know it was the best practice or maybe a technical team that's no longer there again did it, but now they're left holding the bill and it's not good. And it's the senior leadership are , How did we get here? And so that's a really rough thing to do. So the cost of building the block is really the lifetime cost that you need to evaluate. Right. It's total cost of ownership. And it comes down to decisions. what's the total cost of ownership on that decision? We have that for everything, right? Whether it's a clone block or something else. Every decision we make has a future cost. So we have to consider all that. I have another item. Yeah. So even if that block is working, you cross your fingers, you got lucky, it works. You don't now have the new features that we just deployed to the new block. So you have got an old version of that block, but you're missing all the features and awesomeness that we put in the new version. Yeah, and sometimes people come to us and say, think there's a problem with my instance because you guys talk about this new feature, I don't see it. The documentation refers to it, but that's not what I see. And then you look at it, you're , Oh, yeah, that's not our block. That's a very old version of our block. You have a cloned version. Clones are bad. Yes, cloning is bad. Not God's plan for nature or for Rock. But then I think there's other issues that we're starting to run into. As Rock matures, we come up with the case where sometimes we just can't upgrade a block. We have to make a new version of the block. And so we've seen that a few times where we have what we call V2 versions. And when we have those V2 versions, we write what we call migrations between updates, which just simply means it's a set of instructions on updates that says, okay, take this block type and replace it with this block type. Well, if you have a clone block, we can't do that. So it often leads to you not getting these new versions of blocks, which today is , okay, we haven't had that many, but with Obsidian, all blocks are eventually gonna have to go through that metamorphosis where we say, okay, this old block, this legacy block needs to be replaced by this new next gen block. And we can do that as long as it's the block that we know of. But when you put a different block in, it's not gonna work. And as we are literally getting close to having close to probably a hundred of those ready and there's another probably 300 behind it. At least. That's gonna be a very hot mess if you have clone blocks. So we started with in version 16, a handful, I think six or eight. In version 17, yeah, we're planning on doing 80 to 100 swaps or chops. So we'll go target that old block type, but if you're not using it, it's potentially going to cause a headache for you. Yeah. And hopefully not us. Because their problems often become ours. I was going say, the community's problems becomes the core problem. And again, it's often not the person who made that decision. That's right. And it's a very frustrating position to be in when you didn't even do it, but now you have the consequences. Yeah. Anything else, Nick, that you can think of? Well, I mean, all of this effort that's being put into creating custom stuff could be directed toward funding whatever changes you wanted into core, and then everybody could have that. So in one sense, it's kind of preventing funding from funding new features in Rock Core. Right, because some of that funding maybe went to a partner to make a quick tactical tweak to the block. So you paid the money, but now you're left with something you have to support forever and the community doesn't have it either. So it's kind of a- Double loss. Yeah, it's a win lose lose. Yeah. So that's what not to do. In a lot of these, what not to do is really looking at what's in front of you today at the present. What does the future look ? How should we be thinking about that? We definitely should be keeping an eye on the future because all we know about the present is that it's passing, right? And so the future is going to be our reality. And it could be a pretty messy future if we're making decisions that are only good for today's issues. Think about this. Your future leadership team is going to be potentially stuck with these issues. Have empathy for their position. Probably most of us won't be retiring from the exact positions we're in right now. So whether we're making those changes ourselves or whether we are hiring someone else to make those cloned blocks in our system, it's likely that as the the person making those decisions or executing that work, we won't be there. And so our leadership team is gonna be , what happened? I have empathy on their position in the future and don't put them there. Also, if that's hard to imagine, have empathy for your future self. I don't know if you're me, but you may wake up one year from today or six months from today and realize that you really wish you'd thought ahead and if you care for your future position and what you're gonna have to work with, don't make the problem worse in the future than it is now. And finally, just don't pass that issue on to the future team that's gonna be working there. what it's to run into an issue yourself and something's unexpected and there's a price tag with it, and that makes it even harder to deal with. So have empathy for your leadership team, for yourself, and for the future technical team. Great. So Nick, what are some other things that we should consider as we think about this? Well, first and foremost, stop the bleeding. Put a plan in place to figure out what you're going to do next. But stop creating new blocks. If you're still getting pressure from your management to do it, I would sit down with them and put a PowerPoint presentation and explain all the cons. If they knew the consequences of that, I'm sure they would say, okay, that's a bad idea. Yeah, because sometimes they're the ones asking for those small changes and you might think, well, they're the ones who wanted it, but they're not getting the whole story. They're not saying, okay, I can do that. But if I do, we will have a future maintenance thing that we have to make and fund forever. And if something ever happens to me, you're not gonna be on a supported version in the sense, you're gonna be a much different version. Right, so if it comes up again and , well, no, we wanna add that feature, well then go talk to a partner and get it into core. Insist that it goes into core. Yeah, which is a good point because one of the other things that we want you to consider is because this is such a big deal, we've actually asked the certified Rock partners, service partners, to not do cloned blocks. So it's that important because we certify them that they follow the best practices. And so because this is an anti practice, , we can't have them do that. So that's something to consider is that that's how strong we believe this problem to be. Which kinda you might be thinking, well, why is this coming up now? First of all, it's a good thing to talk about in our best practice series, but we've actually seen several churches come to us with this exact problem over the last six to eight months. And so we're seeing it more and more. And these aren't small amounts of changes. There's churches with There's one with 21 clone blocks. There's another one with 33 clone blocks. So we're not talking about a small number of clone blocks. And we're not talking about huge changes. Some of these are really ticky tacky changes, and it's , oh, that was definitely did not justify a cloned block. So we're also seeing performance issues. We're getting reports of, Hey, Rock isn't performing it used to. And when we look into it, it's because of huge amounts of exceptions being thrown, things of that nature. So it's dramatically impacting Rock. And I think it's just us. We always knew that there was occasionally a clone block, but we didn't realize how big it was. And its impact to Rock's reputation. In fact, we had a church, I think you talked to him, Emily, that said that, Hey, was considering Rock, but I was talking to a church running Rock. And they were telling me about the problems they had. It's gonna be so expensive to fix it. And we're just not sure we wanna get ourselves into a situation that. Yikes. And sometimes the problems get worse as they go on because those blocks are not getting the maintenance they need and everything. And so it's really, I think we're seeing the tip of the iceberg of that problem. And that's why we thought this has to be the first one to talk about. That it's not a small thing, that it sounds a small thing, but I think the future of Rock's reputation in a lot of ways hinges on decisions this. That what makes Rock unique is its extensibility. What Rock make what why Rock's unique is because of its power because it's a LEGO kit. But you can do some, , what LEGO would call illegal builds. There's certain things you're not, that Lego will never ship a kit that does certain techniques because they're not structurally sound and they know that. And I think it's the same way with this is that we can really damage our reputation if we do this. I think we're actually kind of starting to get a little bit of that. And that our team is super receptive to things. There was this example last week where someone put an idea in and by the end the week, the idea was actually implemented in code. And that wasn't a funded feature. That was something that we go, Oh yeah, that's actually a good idea. We can do that. So I think it'd be different if there was no response from a development team that that was your only option. Even then though, I would think twice, full cost of ownership of that. But we're here to make those types of changes. And occasionally there will be a time when we just simply can't because it's not what's good for the performance of the product. It's not what's good for maybe it forces us to change the behavior for other churches that might want a different way. But that's pretty rare because of block settings and all kinds of other settings, you guys have seen that. We have a track record of being very responsive to the community on that. So there really shouldn't be a good reason to clone a block or fork a block. So that's our first of best practices. We are putting this content into a blog post also that has a attached video that covers much of what we just went over so that you can share it, maybe even with your leadership team if they don't understand or if you wanna get a recap of some of these reasons. But we hope you enjoyed the first of the series, but we'll have much more. I can't wait to talk about some of the other best practices and the dos and the don'ts. And thank you to the community for asking for this type of content. So it's something we're excited to help with and definitely is a hot topic right now. So hopefully that's been really helpful. And as a last few couple of announcements, at the time that we're recording this, we're closing in on the last month of the year. It is hard to believe it. But don't forget, as you're wrapping up and tidying up your budget for the year, if you have unallocated funds currently, it's a great time to purchase your RX tickets. And it's also a great time to make a little extra donation to Spark to help us as we continue to build this generation of Rock, next generation of Rock, be super responsive to issues and needs of the community, and push hard into innovative new features that have not yet seen the light of day. So we appreciate our donors. We appreciate you in the community who are able to help make that happen. And we just ask that as you're considering your end of your budget, you consider those two things as well. Thank you so much for tuning in and listening with us. Please don't forget to subscribe so you can hear our next best practices and other podcasts. Thank you for joining us today, and we look forward to sharing some time with you at our next podcast. Do a church that loves the idea of using Rock but hasn't taken that leap yet? With managed hosting, churches of any size can get access to Rock's amazing technology, hassle free. With just one click, Rock's managed hosting removes the roadblocks that might stop a church from switching to Rock by making the process simple. Churches get the ease of a SaaS church management system without losing any of Rock's powerful features. Are you ready to take the next step or share with another local church? Visit rockrms.com/hosting today.