148 Should I Build a CMS or Should I Buy One?

Should I build a custom content management system (CMS) or should I buy one and make it work? What should I think about when considering building a CMS? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:26

Should I build a content management system or should I buy one? This is a question that came up on the suggestion site, and it's one that I really want to answer because I hear it a lot. In fact, I don't really hear the should I buy one, I just hear the how do I build a content management system or CMS. So let's talk about it in today's episode of Dev Questions. Now, I'm gonna give you the quick answer right up front, and then we'll talk about why. And my answer is not gonna be it depends. It's gonna be buy it. If at all possible, buy it. If it's even close to what you need, buy it. Let's talk about why. And we're gonna start with a little bit of history from my background. So I was hired by a college, they're now a university, where I was hired to be a developer, a software developer, to help them continue the building and expanding of their content management system. At the time, it was a small college, and they had one developer that had maintained and created and maintained their content management system, custom development. And I spent a year evaluating, upgrading certain pieces, figuring it out, and trying to figure out how do we make sure that we can get this moving forward and also make sure that it is stable, make sure it is compliant, and all the rest of the things. So that was my job for one year at that college. At the end of that one year, I became the IT director and immediately went out and purchased a content management system. I we moved all the data off the old CMS and put it into the new one. We spend a significant amount of money in order to move to that new CMS. And it's a decision that I would go back and do the exact same way if I had to do it over again. So let's talk about why I did abandon my job? Why did I stop becoming a developer, become the IT director, and just get rid of the existing content manager system? Because it was customized for that organization. It was specific to them. And so what they wanted to do specifically, it exactly did what they wanted in theory. Now, as we know as developers, that's never really the case. But let's talk about what were the things that maybe go, I don't care if you already have an investment in this, throw it out, spend lots of money, and get something different. Well, the first one is data security. Now, you may think of security, you think, okay, vaults around your server room. That's not the only thing that you have to think about when it comes to data security. For instance, this CMS housed student records, including their grades. So my you know, kind of joke at the time was hey, you know, if you pay me enough money, I can change your GPA for you. Now, obviously, as a total joke, I never did that or even came close to doing that. Um, but I could do that because there was no data security in place to make sure that what was changed was tracked. Who did it, when they did it, why they did it. That wasn't in place because it just had a place for your grades. So if I could change your grades, then your GPA would change. That's not a great thing. You have to have security around your data. You have to have some data be super protected. For instance, if you have a social security number or other government ID that's that's private, well, it can't just be into the rest of the data and just out for area C. You have to make sure that it's encrypted and it's obfuscated, and people have limited access to it, and you can track who has access to it and so many other things. But then there's some data that, like grades, you need to track when they changed by who, make sure there's a change tracking system in place to make sure that you can trust the data. And there's things like making sure you have good backups, and that's just physical security, but making sure you have backups so that if something happens, you can roll back. And it's not just did the server blow up, can we restore somewhere else? It's what if someone goes in and this happens to every new DBA and existing DBAs, where you say delete from table and forget to put the where clause. You just dropped an entire table. How do you restore that well? How long does it take to restore? How much data did you lose? What about the integrity of the other tables? And so many other questions. So security of the data was a big deal. But then that's just the first layer of issue. Next up is compliance regulations. There are so many different compliance things that you need to be aware of, you need to track, and you need to make changes based upon them. So, simple example, the CAN spam act of whatever year it was. Um, what does it track when you send out email and make sure that if you're sending out spam email, email the user did not request, that's marketing related or even transactional, that's not really supposed to be, that you get fined for that. And there's some big fines for that. Well, if you have an email address in the database, what's to stop a user from sending out emails using just the database list? And that's a problem. You have to track when they unsubscribe and making sure they can unsubscribe, and so many other things. You have to put those things into your database to make sure that you protect yourself against something as simple as the CAN Spam Act in the US. And there's one for Canada, there's one for the GDPR covers that in Europe and so on. And the GDPR, don't get me started, there's lots more stuff in Europe that you need to think through, like making sure that you can forget someone fully. So if they say, hey, get rid of all my information, you have to be able to do that. Well, every time a new regulation comes out or gets changed, you have to know about it. You have to write the code to comply with that, and you have to validate that you are doing it. And then you have to train all your users on how to do that well. You're it. You have to do all that. There's a mountain of regulations. And as the world becomes more and more global and less and less my little town, well, more and more regulations apply to you because you'll have students from Europe coming to the US and you have people from Canada coming to the US, or if you're in Europe, you have people from US and Canada, like all over the place, kind of intermixing, and now you have to comply with a lot of different regulations that you might not otherwise. Online education will make that even harder. So just with a just with a college, that becomes quite complex. Next up, reporting needs. Oh my goodness. Everybody decides they want to have reporting in a different way. And you might say, hey Tim, you know what? I'm just gonna dump it into a reporting database and say, go crazy. You can't do that. You just can't do that. Because again, some people shouldn't have access to certain things. Some people can have access to certain things, but they shouldn't be reporting on it. Some people can have access to things, they can report on it, but you need to track when they report on it. All kinds of things you need to think through. And there's a broader category that we're already talking about, but that covers more things, and that's just the word risk. You have to be able to evaluate your risks, evaluate where the problems are, evaluate what you are risking when you go this direction. And oftentimes you don't when you're building it yourself. You just say, hey, does it work? Well, that's the very baseline, simplest explanation. You have a whole lot higher bar to jump over to say, should we do this? Okay. And then also maintenance costs. Again, I was hired as a full-time developer to work on this system, but I was the only developer to work on that system. Well, the college wasn't that small. There was a lot of needs from a lot of different departments that always came in. And so what happens is you spend most of your time dealing with feature requests. People who want more things, want different things, want things changed. Then you have a whole list of bugs that you need to squash, you need to fix, but the feature list is always the important one. Okay. So when the vice president comes to you and says, I need this for this department, they don't want to hear, well, but I have three weeks worth of bug fixing to do first. So their features usually get put ahead of any kind of like maintenance or making sure the system continues to work well. And so what happens is you have this ever-increasing, never decreasing seemingly, list of features and upgrades and changes to the system that are in your inbox. And then you have all the maintenance you're putting off that's that's risking your system. And then you have all the things that fall even further back, like compliance, where yes, you absolutely have to be compliant, but no one wants to hear, I need to stop doing development on any feature requests in order to make us compliant over the next month or three months. That just doesn't isn't acceptable in most places. And typically, if you're building your own CMS, you don't have a massive team. You have a few people at most, or maybe just you. And in that case, you just don't have time to do both. So you have to work on the things that your boss says you have to work on, but you also have to be responsible for all the things that are kind of hidden and behind the scenes and seemingly aren't important, but really are. So what happens is you have a system that is not compliant, you have a system that is not regularly checked for data security, you have a system that is really built on a house of cards, but it still seems to work. And so the management doesn't know that it's built on a house of cards or they don't care, and they don't really comprehend that. And so what happens is they keep asking for features and over time it bloats, and at some point it collapses. And when that happens, the fingers point at you. And so I recommend it. Now it didn't happen to me. Again, I I was the one that kicked it out, but it I've seen it happen a lot. I've seen a lot of people that have been really enthusiastic about we need to create a system that is tailored to us because we are so unique that we have to have something that no one else does because it would make us better. My recommendation to you is to say we can't afford it. That's it. You can't afford it. So you're not that unique. You're not unique in all of the universe. People who, you know, if you're talking about salespeople and you want a content management system for handling, you know, tracking clients and all the rest, there's lots of companies that do that. There's lots of existing systems that do that. Find one that's close to you. There's going to be an 80% coverage of what you need to do. That's good enough. Okay. If you're talking about a school and having admissions and tracking your uh grades and all the rest, there's lots of different organizations out there that do that already. There's lots of colleges, there's lots of universities. And so find out what they're doing because they're not all doing unique systems. Instead, they're purchasing something off the shelf. And so find what that is, find the one that works for you. So you're not as unique as you think you are. Therefore, you can get away with using a non-customized system and maybe even customizing it from there, but at least getting a good foundation built by someone who has the time and who is doing data security and updating for compliance regulations and is creating standardized reports and managing your risks and taking care of some maintenance. So all the things that are a danger to you, that they're doing that. And you pay for that, but at the same time, you're paying a lot less than if you were to do it yourself and do it right. Okay. Now, developers, as developers, we have a couple of tendencies that we need to talk about. The first is we tend to see the flaws in things. We see an application and say, that's not right. That could be better. That should do this. And that's a good thing. That's that's a good skill to have to be able to identify here's the problem, here's how I'd solve it. That's absolutely a good thing. However, it can be taken too far. Like any any good thing, if you do too much of it, you're gonna cause yourself some problems. You're gonna take it from a good thing to a bad thing. So if you spot the flaws so much and say, you know what, nothing is good enough, then you start deciding that, well, I'm gonna build it myself because if nothing is good enough, then I can do it better. Therefore, that's the best solution. The funny thing is, we never seem to spot the flaws in our own application in the same way we spot the flaws in others. So be very careful to evaluate yourself as well as everything else when you're comparing apples to apples and say, you know what? You know, there's this flaw and that flaw and that flaw in that software, but it's already got five years worth of work into it compared to what I would have to do to get to that point. So three flaws versus five years of development just to get to the point where they are five years late. It seems like a no-brainer choice, but you need to make sure you're honest about that. And the second tendency we tend to have as software developers is we underestimate complexity. And this is, you know, our eyes get big and our stomach is small, and we look at things and say, I can definitely do that. And we find out that, wow, that was way too much. So I've seen this a number of times. Um, and I've done it a number of times because you look at something, you say, hey, I can solve that. That's a simple problem, I can solve it with a simple solution, you know, and this is how I do it. But what we forget is that a proof of concept is not the same thing as a completed system. Meaning I could create a system that would track users' grades. And I could do that in afternoon. I could build something where you could input grades, you could track grades, it could calculate GPA, all the cool things, right? I could do that in afternoon. But that's not the same thing as a completed system. Is it compliant with regulations? No. Does it have a great authentication system that is granular and makes sure it protects the data and tracks data changes and makes sure the data is backed up and is redundant and all the no, it doesn't have any of that kind of stuff. And that's really one little screen of a much larger application. Because where the students come from, where the classes come from, where the professors come from, what part of the database do they go in? And then, okay, now you have professors on database. Are you tracking how many classes they're teaching and when they're teaching, the scheduling, and making sure they're paid correctly and for the level they're at, and what classrooms do they have? And do you have a management system for where the classrooms go and how many seats are in the class? And the list goes on, expands out as you start to pull on the thread of I want to attract students and their grades. So don't confuse a proof of concept with a completed system. They're two different things. All right. So my recommendation is when you get tempted to create a content manager system, just don't. Just don't. Um, it's it's a project that every developer at some point seems to have wanted to do or even started to do. And you know what? If you have some free time, build one. Go for it. Have fun, build it out, but make sure that you're honest about it and what it does, how it works, how secure it is, how compliant it is, and so many other things. And then I think you'll find that it never really gets completed for some reason. So you absolutely can. And just to be clear, there are content management systems out there. Someone has done it, but typically it's a much larger company that has done that. Or it was a small team that started it, but over time they have grown in order to do all those things that you need to do. Or, and here's the dangerous part, they haven't done all those things. So it looks great, it seems to work great, but it's not compliant, or it doesn't protect the data properly, or it's not secure. Or be careful. Okay? So that's my thoughts on content management systems and when to build them. Thanks for listening, and as always, I am Tim Corey.

SPEAKER_01 18:12

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamtimCore.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.