RX 24 - Custom Code: Just Because You Can, Doesn't Mean You Should - Courtney Cooksey

Transcribed Content

Welcome, everybody. Our next session is gonna be custom code. Just because you can doesn't mean you should. And Courtney Cox from The Crossing is gonna be presenting. Let's give her a hand and make her feel welcome. Is it gonna show up on the? There we go. Alright. So as Jeff Goldblum once said, you were so preoccupied with whether or not you could that you didn't stop to think whether or not you should. Now, he was talking about dinosaurs, but the same applies to us. Right? My name is Courtney Cooksey. I have been living in Little Rock, Arkansas this year, and I actually work for The Crossing in Columbia, Missouri. So today, we are gonna talk about what is considered custom code, what the true cost of customizing is, and when you should customize, and that's a picture of my dog Loki trying to catch a snowflake because dogs are cute. We're going to start by going over some examples of customization, then we'll talk about the cost of customization, then we'll get into what is the foundation for sustainable customization, what key roles do you need to have, how do you choose a development team, and some common misconceptions people have. Then finally, we'll go over some questions you can ask before you customize to help assess your risk with customization and decide whether or not something is worth customizing. Alright. Examples of customization. Hopefully, obvious is plug ins. If you can buy it in the rock shop, if you can steal it from another church's GitHub, then that's a plug in. It's not supported by Spark, but hopefully whoever made it. Changes to core blocks. We have one that pains me to my core, but in the event registration block, at the very end, when it's asking for the registrar information, the text says this registration was completed by and asks you to fill out that info. But we had a senior pastor that kept not signing up for events because he saw that and thought he was done. So we literally go in and make a change for just a few words so it says is being submitted by, but that's something we have to do every single time we upgrade now. We have to just make that small change every time, but it's something that is not automatic. It's not lasting. Then you've got your custom blocks, things that are entirely custom and specific to you only. So for us, we've got a pretty intense event form block, and so anytime a ministry wants to request to have an event on our campus, they have to fill out this form, and it's totally custom and unique to us, but we realized that the amount of time we spent having to pay one of our staff members to tell a ministry, hey, you can't add free childcare to a 300 person event twenty four hours before the event starts, that it was easier for us and it was actually worth it to just make a form where they couldn't even ask for that. It's just impossible. So you'll also have your custom blocks. One that might not be as obvious, but because you're using core features and core utilities, it's just the way that you've customized Rock to make it into your own product. So you'll notice here, this is our person profile, and if you look at all those tabs, you're gonna see some stuff that's probably not in your instance, and this is because we have added some extra pages to the person profile to make it work best for our ministries in the way they use it. Well, when we upgraded to fifteen three, you would tab through those pages, and then suddenly you lost the person ID, and it went to the old layout of the person profile from before, and it might be really easy to think, like, hey, upgrading to fifteen three broke the person profile, and, like, Spark messed up, but actually, it's not. We added some custom things that the migration had no idea existed. Right? It didn't know those were there. That's something we added, so we just had to do a little bit of configuration. We had to go say, hey, we want the new layout on these pages. You have to pass the person parameter, all that stuff, and then everything worked. It was just configuration, nothing was broken, but if you don't realize that that is something that you added to your instance, it could be easy to not realize that's technically something custom. Now you might be thinking, hey, Rock is open source. The whole reason we picked it is because you can make it do exactly what you need to do. Why shouldn't we customize everything all the time? And the answer is unexpected technical debt. We're finding that there's a lot of churches who don't have a lot of technical knowledge. Right? They have little to no IT staff, and they don't understand what it actually means to customize. They don't understand the cost involved. They don't understand what it means long term, And so they're doing all these things, or maybe they had one person who knew it well just said yes to every ministry. Yes, we'll do this. Yes, we'll do that. Who cares? And then they left, and now no one else knows how anything works. So it's all this unexpected technical debt. So let's talk about the actual cost of customization. Whenever a ministry has a problem, they come to you, and now you have to create a product that solves their issue. And to create this product, we have a project life cycle that's pretty standard. First, we gotta figure out who's actually involved, identify the roles. Then we have to start and gather requirements, what actually is involved to create a solution to this problem, to create this product. After we've got all that, now we can enter the development and testing phase. We'll do some development. We'll test it, develop more tests. Do that 20 or 50 times until we feel comfortable that it's ready for release. Then we release it, it's great, our staff is using it, and then all of a sudden now, maybe they find new bugs we didn't find in testing, or they want to make changes, they want new features, we have to start the whole life cycle over. Every step in this life cycle has a cost. If you fail in the requirements gathering, your whole project can fall apart before you even start. I really wish I could tell you that there is a book you could read and just automatically be super great at project discovery and requirements gathering, but in my experience, that's not the case. You need an expert who knows what they're doing. It just takes experience and expertise. You're going to get better at it every time you do it, realize the questions you forgot to ask in the last project, and now you know to ask them in the next one. You also need to make sure that you have a clear issue that needs to be addressed. I can't tell you how many times we've seen a ministry doing something where we've said, oh, hey, we could automate this for you. We could make this easier. Let's do it for you. But the ministry wasn't really bought in, and at the end of the day, they stopped using it. They don't use the product. We just wasted a ton of time, a ton of resources, and it all just falls apart. You also need to make sure that you have someone who can articulate the problem the ministry is having to your development team, your expert. It's really tempting for a lot of people to try to have this intermediary between the technical people and the ministry staff, and the reason is they don't want to confuse their ministry staff with a lot of technical terms. But the issue is that you can end up playing telephone. If your intermediary doesn't totally understand the problem the ministry is facing, well now what are they articulating to the dev team, and what's lost in communication along each way, like when kids play that game of telephone. You also need to make sure that when you're doing this requirements gathering, you have an expert in the room who's the one to provide the solution to your ministry. You also have to know that every requirement that you add to a project is gonna add up. If you need a solution by next Sunday, you don't have enough time to build something custom and test it and make sure it works before that goes live. But if you've got two months or six, well now it's a lot safer. You've got time to play with. You've got time to test and figure out exactly what you need. Optimization is not free and it's not easy. If you've got some really complex logic, then you need to think about who's using this product. If it's one staff member a couple times a year, then maybe it's okay that a report takes thirty seconds to load, but if this is something on your public webpage that hundreds of users are going to be using every single day, that has to work efficiently, and it doesn't just magically happen. You need experts that know what they're doing to be able to optimize that. You also have to think about external data. If there's other apps that you need to talk to, maybe send data to, pull data from, Well, now your development team not only needs to know Rock, but they have to learn that application too. Then we're gonna get into creating the actual project. Do you have a team that can create the right solution for you? If you work with a team that doesn't really have a lot of rock knowledge, maybe they're cheaper, maybe they're even able to build you something that works, maybe it goes okay, but it's probably not going to be the right solution. It's probably not really going to integrate with rock. They're probably just going to kind of build something that sits next to it. It's probably not going to upgrade well. You're probably going to have a lot of issues long term. You also need to make sure that your development team has the tools that they need for discovery. You can't tell them halfway through a project, oh, hey, there's all these other requirements we forgot to tell you about. If our digital team comes to me and says, hey, we want a page to display our sermons, great. I'm gonna create a content channel where you can create a sermon for every content channel item, and then I'm gonna create a page that will pull those in and display them. If I'm showing that to you and you say, oh, well, actually, our sermons are in YouTube, and we don't wanna have to enter them into Rock, we just wanted you to pull them from YouTube, well, everything I've built is completely useless. That's not a requirement you gave me at the beginning, so you need to make sure that your development team really knows exactly what they need to build. Development is a team sport, and your development team is not the end user. No matter how well you explain the problem to them, they're going to use it differently. It's up to your ministry team, whoever owns the product, to be the one to test it and says, yes, this product does what we need it to do in the way we need it to do it. And you also have to know that you were just always gonna be surprised by end user behavior, and these are real quotes, yes. So with our event form, we had just done a release, and then a staff member comes to us freaking out, like the event form is broken, the submit button is grayed out, I can't submit an event, you guys broke this, it was very dramatic. Well, please feel free to heckle him before the end of the conference. And we've got some tracking software on the page exactly for this scenario, so I went and watched what he did to see what was broken, and I found out that he never picked a date to have his event. We never expected someone would try to submit an event request that didn't have a date that wasn't something we anticipated. So you have to know that you're always, no matter what, no matter how well you test, something is gonna happen that you're like, why? Why would you do this? But hey, we learned from it. We added some extra text to let you know, hey, you can't submit this because you didn't pick a date. Custom code requires custom upgrading. I cannot say this enough. If you upgrade without testing, you are just asking for failure. Technology is always evolving, and we're not writing code that tells your computer, like, hey, send electricity from here to here and do things. Like, no, we're not writing that. So we rely on the Microsoft stack, and then we build Rock on top of that so it does all the things that we need Rock to do. But that means if Microsoft says, hey, this version of all these libraries is deprecated, there's security issues, and we're just we're done with it, we're not fixing them, we're moving on to this version, well, we can't just keep Rock on these old versions. We have to upgrade to those new libraries, and sometimes there's breaking changes. So then we have to fix Rock, and now Rock has breaking changes that now your plugins have to deal with, and it's all just a downstream effect. You also have to remember that Spark is not responsible for your custom code. I went and looked. The Rock code on my laptop is like 11 and a half gigabytes. There's over a hundred thousand files, and Spark has enough to deal with with that and all the new features that they're adding every year. They don't have the access or the responsibility to maintain anything outside of that. So you can see how you start with this small design, this idea for this product, and it's pretty small, seems manageable. Well, then we get the requirements. Okay. It's a little bigger than we thought. We enter into development and testing. Well, that takes time. We've got our ongoing maintenance after that, bugs we find, things we didn't expect, and then we've got rock upgrades. And now we can see how we started with this very, very small design, but it's 10 times what we thought. So how do we set ourselves up to be able to do customization? How do we have a foundation for sustainable customization? Well, we're gonna need some roles. First is a product owner. Now I'm gonna talk about two product owners here. One is the product owner of Rock as a whole. You need to have one person who oversees your Rock instance. They need to have the vision and the management, and you also need to give them the authority to manage that, to tell ministries, sorry, we're not gonna do that. You need to have that one person who owns Rock as a whole, and they need to also have the expertise to be able to learn what's in rock, what's available, what's upcoming, and maintain that. Then for every project you do, you're gonna have a product owner for that project. This probably isn't gonna be the same person because usually your projects are gonna be for a ministry. So some leader in that ministry will probably be the product owner for that project, and they need to be ready to be actively involved in the project life cycle. Their responsibilities during the project life cycle is first and foremost going to be they decide on the project scope. So every task that gets added to what makes up this project, what's the end result that we desire, the product owner is the one who decides what that is, where it stops, where it starts. It's also really important that no task gets completed until the product owner says, hey, I tested this, I verified this. It does what I think it should do the way I hope it would do it. They're the ones that need to say this is complete. I even, to the extent, in our project management systems, I will not click that button. I will not check that off. I will not mark something complete. The product owner needs to do that, and I think it's a really helpful visual reminder for them to say, like, no, I'm taking the ownership to mark this as done, to say, yeah, we're we're done with this. We're moving on to the next task. Then finally, extreme ownership. Most projects don't fail because of one person. Right? It's a lot of little things. There's other things outside of your control, but really, whoever is the product owner for a project needs to be ready to accept total responsibility for the end result of the project. They need to be the one that says, if this failed, that's on me. I didn't own the product well enough. Next, you're gonna have stakeholders. This is gonna be anybody who can influence the product. It might be senior pastors, ministry directors, staff members, even church members. And their main responsibility is just gonna be collaboration with the product owner, but it's really important that your stakeholders should never make demands of your development team. They can advise the product owner. They can work with them, but all decisions about the project need to come from the product owner. And this is because if you don't do that, then you might up in end up in a situation where we had a product owner for our public website as a whole, but he didn't really like to be involved in all the smaller projects throughout. So he would pass those off to other staff members without giving them the authority of being a product owner for whatever we were working on. So I would be working with a stakeholder, we would do something, he would see it and say, nope, that's not what I want. And then we just wasted all that time, and we have to redo it, and we have to do something else. So you need to make sure that your stakeholders are not asking for things, that you're not going back and forth, well, I want it this way, I want it this way. The product owner is the only one who says this is what we're doing. This next one isn't really stereotypical in the tech world, but I think it's really important that if you're gonna let somebody influence a product's design, then they better be sure to be part of making sure it works. Invite them into testing. Make them part of that. Make them help you out so it doesn't all fall on one person. Next, we've got our developer role. This isn't necessarily going to be a software developer, it could be, but it could also be that actually the solution is just some complex workflows and anyone who knows Rock really well could build it. The developer responsibilities, first and foremost, requirements gathering. They need to fully understand the issue that the ministry is facing. Then the developer needs to take that and go do some research, spend some time analyzing, evaluating all the possible solutions, working with the ministry to figure out exactly which one is the right fit. And then finally, they actually have to create the product. Now, whether you have a developer on staff or you contract with a development partner, you always have this client contractor relationship between your development team and your ministry team, and you can kind of have your developer team play two roles, that of a consultant who can actually collaborate with you, understand the ministry needs, and actually help you find the right solution, Or that of an executor that just, you ask me for this specific solution, and I build it for you no matter what. I'm not even gonna try to warn you about the consequences anymore. Like, we're just in this path of, like, okay. I will do it. I've tried to tell you this is not good, but we'll do it. And let's talk about the difference between that. So on the left, we've got being a consultant. So your product owner is bringing the development team a problem they need solved. And on the right, we've got when you're an executor and the product owner is asking the dev team for a specific solution. Well, if you ask for a specific solution, that solution will get built. But if you bring a problem, then we have collaboration and discovery before the solution is built, and we know at the end of that the problem is solved. But on the other side, who knows? We actually had a really good example of this recently. So we have a ministry called Agape, which is our disability and inclusion ministry. And on our Rock instance, we have a person attribute that just says whether or not someone received support from this ministry. You can see how that would be kind of sensitive information, so we lock it down so that it's only visible to our Agape staff. Well, our college ministry came to us and said, hey, we wanna be able to see this person attribute. We got them to say it's okay, so just give us access. And that sounded kind of weird to us, and we were also thinking, a, why do you need this? B, is that really okay with them? Because we know their values and we know why this is locked down. So we challenged that and we went back and we said, hey, can you tell us what problem you're facing? Well, it turned out, what they actually wanted was on all of their event registrations, they wanted to ask a new question. Hey, Agape is our disability and inclusion ministry. If the registrant for this event could benefit from that, please say yes right here. That's what they wanted. They wanted to be able to see when someone signed up for an event if that person would benefit from support. Well, they wouldn't have gotten that if we just gave them access to the person attribute for anyone new, and it also wouldn't have just magically shown up on all their event registrations. So you can see how it's really important to be a consultant and be in that place. I would say if you're a church, you need to make sure that you're inviting your contractor, your partner, to be a consultant for your church. Tell them you want that relationship with them. Tell them you're willing to have that. Get that feedback, which maybe sometimes mean they're gonna tell you no. Right? And that's a really hard thing. That's hard for them. It's hard for me to tell our staff, hey, we're not gonna do that. That's not good for you long term. And if you tell a partner if a partner tells your church that too many times, they're just gonna stop working with you. Right? You're gonna be like, hey, we're done. You keep telling us no. Like, we're we're out. But when you lock them into being an executor, well, then that's how you get all this huge buildup of, well, why didn't you tell us that if we did this customization, we wouldn't be able to upgrade magically? Well, maybe they did at one point, but you've gotten to the point where they've lost that trust. So you need to make sure that you have that. You're asking them to be a consultant, and if you're a developer that feels like you've been boxed in to only being an executor, you need to let your ministries know that, like, hey, I don't feel like I have the trust with you that I can tell you when something's not good for us long term. Let's talk about choosing a development team and how it affects whether or not you should be able to customize. Budget is obviously a big part of it. Do you have enough money to have a developer on staff? Is that somebody fresh out of college, a senior developer? Do you have enough money for a whole team? Or do you have enough money to have a retainer with a partner? You can't have someone on staff full time, but you can regularly have ten, twenty hours a month with a development partner. You're probably in pretty good shape with either of those to be able to do customization. That's sustainable. You've got access to development time long term. On the other hand, if you're like, budget's tight, we've got enough budget to do one project, and then we will have no budget again for another year, well, that's a lot riskier. You're probably looking at, like, what can we do with core features to meet this need? You also need to think about rock expertise. You may be able to find a development partner that's cheaper but have never worked with rock before, and they don't know what they're doing, so you need to make sure you're asking, hey, does this contractor regularly work with rock? Maybe they only work with certain parts of rock, like payment providers. They're probably not gonna, you know, build you content channels or connection requests. You also need to think about your level of Rock knowledge. Does your team know Rock really well? Do you guys have ideas about what all Rock can do, the rest of your staff? I would say if both those are low, if your church's level of Rock knowledge is low, if your partner's level of Rock knowledge is low, that's gonna be pretty risky to customize. You also have to think about what services does this partner actually provide. Ask your partner that you're considering, like, do you do custom software? Because not all of them do. So you have to make sure that's something that they offer if that's what you want. You also have to think about maintenance. Does your contract end as soon as your release date hits? What if you find bugs after release? What if you want new features? Is this a whole new contract? What about upgrading rack? Who's checking that, maintaining that, fixing any breaking changes when you switch versions? Let's talk about some common misconceptions that people have with development. The first is that people think you should ask your development team for specific solution, and that's not true. Your development team is in charge of providing the solution. If you box them in and say, do this, I mean they'll do that, but it might not solve your problem. So don't limit them. Don't do that. Make sure you're bringing them a problem and leveraging their expertise to give you a solution. There's also this conception that, well, the development team already tested it, so I don't need to, but the development team is not actually responsible for testing at all. That's your product owner and your stakeholders. You're the ones who know how this needs to function for your church, so you have to be the ones to test and say, yes, this is working, and you've gotta do that in the testing and development phase, not after release. There's also this misconception that you shouldn't expose ministries to alpha versions of products, and I understand where you're coming from, but I really think you should bring in a diverse group of testers. You can have a few rounds of testing with your core people who are working on the project, but then bring other people in. You know, no matter what, that there's that one person on staff that as soon as you release something, they're gonna do something that you're like, why? Why would you ever do that? We never considered that. So bring them in early on and get those bugs fixed, those things, those scenarios handled and out of the way while you're still in development and testing so that you can have a smoother release. This is in our takeaway, and this is an example of what we do every time we upgrade Rack. This is our migration checklist. Right? We read the release notes. We figure out, hey, what's new? What might be a breaking change? We take a copy of our production database, which don't worry, yes, this isn't a takeaway too, along with some other, like, testing tips too for specifically M projects. We take a copy of our production data. We sanitize it. We hook it up to our test server, then we upgrade that, now we go through testing critical functions, because remember, right, Rock is a community product. There's alpha and beta testing teams, but they're only testing Rock the way their churches use it. You might be using it differently. Our check-in scenario is entirely different than anyone else I've been able to find, and so we know we always need to check, test, check-in, and make sure does it work the way we expect it to because those other churches aren't doing that. They're testing Rock the way it works for their church. We've all got to be part of that community to support this product. So we've got to do that. You've got to test all your custom stuff, your custom blocks, your modified core blocks, and then also the things like maybe you have a ton of HTML blocks with custom lava or other things, custom workflows. You gotta test all that. After then, you go through, you fix the bugs you found, you do the upgrade development you needed to do, do another round of testing, make sure it works, invite more staff, say hey, go do the things you have to do every single week, make sure it's working, and if it's not, then let us know and we'll fix it. And then that way you don't have a huge backlog of all these ministries right after you upgrade your production server saying, hey, this doesn't work anymore. You've gotten that out of the way, and if they didn't do that, well then, you invited them, you gave them the opportunity, that's on them, and sorry, you've gotta wait. We've got these five other ministries ahead of you. Also, make sure that you create a list of all the things that you needed to test that were custom so you can reference that next time. We just copy our project so that we can just reuse it every time we add to it constantly. Alright. Let's go through some questions that you ask before you decide whether or not something is worth customizing. So first is just kinda how can you assess your risk for customization? I think if you can devote time and expertise to discovery, you've got consistent access to a development team, you've got ample time before you need the solution, you've got a lot of expertise in rock all around, a dedicated product owner and a commitment to testing, your risk for doing something custom, pretty low, pretty safe. On the opposite side of that, if you're not gonna spend the time to do good discovery, if you don't have a good goal in mind, don't have a lot of time with developers, don't have a lot of time before you need a solution, limited rock knowledge, nobody to actually take that ownership, or nobody committed to testing, then it's likely that if you do something custom, it's gonna break, and it's not gonna go well for you, and you're just gonna be fighting fire after fire, and it's gonna feel like every time you try to upgrade, it's just a nightmare. So the first question we always ask when a ministry says, hey, we have this problem, we want this custom solution, we're like, well, can people do their jobs? Because if it's actually stopping you from doing something that is critical to your job, we are way more likely to say, yes, let's get you a custom solution. If it's not, then less likely. Next, we're gonna ask, is there a workaround? It might not be pretty, it might take longer, but if there's a way for you to get from point a to point b, then we're still probably not gonna go down a custom route. Does the issue affect primary operations? So for us, it's Sunday morning sermons, giving, signing up for events. If it affects one of those, then yeah, we're probably gonna customize to make a solution, like that's core to who we are and what we do. You have to think about those things for your church, and what would say, yes, this is important enough, we would go custom. Is there a solution in Core? Maybe it's in the next version of Rock, and can you wait until you upgrade? Or maybe it's not quite the UI you wanted, it's not quite the experience you wanted, but you actually could, like, chain some workflows together and get the same end result, well then we might go that route instead of making something custom. If we can actually do it in core, we're much more likely to do that. And then finally, how do you upgrade? Because if you're not gonna test, then you probably shouldn't be doing custom stuff. That also includes if you test version 16 o, but then you upgrade production to sixteen five, well, didn't really test then. You gotta test what you're actually gonna go to. You gotta make sure it's good, accurate testing when you upgrade. And then just remembering that, right, that initial idea multiplies so much at the end of this. It's not the original cost that we think it is when it's just this pie in the sky idea. So you really need to make sure you own your rock instance. Someone's got to be in charge of doing the management, having the vision for it. You have to test. You have to test. You have to test. You have to test. It is so important. And then you also have to just be honest in your self evaluation before you decide, should we customize? Are we ready? Do we have the foundation for it, or is this gonna be a train wreck for us a year from now? Alright. That's all I've got if anyone has any questions.