Maintenance is a good idea for every website, but it's a requirement for websites using open source code. The upside of open source is that everyone can participate. The downside is that means keeping up with everyone's changes. Code gets patched, which causes other code to stop working and need patches in turn. Exploits are found and then blocked. Fancy new features are developed, and your users want them. All of this means you need to keep up! The most important weapon to combat these forces is maintenance. Maintenance is a simple process, but there are basic mistakes that many people make at least once. Avoid these and you'll be well on your way to a safer, cleaner website that isn't a huge pain to keep running.
1. Reinventing the wheel
Look, we've all been there. Three different departments have reported the same bug. You've been trying to track it down since you came in this morning, and you missed lunch two hours ago. Whoever wrote this code was an idiot, and the documentation is practically non-existent. All you want to do is wipe every file off the server, delete the database, and start from scratch. You're certain you can do a better job than these morons. It can't be that hard to write code to run a membership site with six payment gateways and an editing GUI... Especially if you use your favorite language.
When this happens, take a deep breath, walk away from the keyboard, and eat a sandwich. A custom-coded solution doesn't save time up front or during maintenance. You'll have to solve issues the current code sidesteps or has fixed. You'll mess up everyone's workflows, which means handling customer service complaints. Users will ask for all sorts of brittle, custom workarounds. And then you'll have to patch and maintain the codebase, in addition to the rest of your job.
Even if you could do better, are you being paid to rewrite something that's already mostly working? If you're frustrated enough to take it on as a hobby project, is that what you want to spend your weekend on? GitHub is chock full of not-all-that-unique content management systems (CMSes) and static site builders. Most of them are abandoned, clones of more popular systems, or both. Don't be yet another one.
For those who don't code, this pitfall looks different. In that case, be cautious about changing your website's technology. All systems have costs and cons; when you come across a shiny new system, often you can only see the pros. There's also the problem of technical debt to consider. When you switch systems or replace an extension, your staff has to learn how to use it. You or your devs have to learn how to maintain it.
I'm not saying that custom code or a new system is always a bad idea. Just make sure that's the best solution to your problem before leaping in.
Instead, use software that's being maintained by others, and change your setup cautiously. Despite its limitations and frustrations, this makes maintenance faster and easier. You might have to deal with a patch that breaks something it shouldn't. But that's exactly what would happen with a custom solution, too.2. Biting off more than you can chew
Folks tend to get overexcited about new technology. The temptation to add lots of features and functions to a website project is strong. The number of options for modern websites and apps can be thrilling. But I've seen lots of websites with more functionality than their audience needs or uses. Even if your visitors don't use it, you still have to maintain it.
Don't get too gung-ho about early plans for SEO strategies and payment systems. If you don't know what your audience wants, you'll build too much of the wrong thing. Not only that, but a website is generally only good for about five years at most. After that, the design of your site will be dated, and the state of the art will have moved on without you. Your juggernaut website will need to be reworked to fit new business needs or the evolution of the web. A big, complicated website has big, complicated maintenance needs.
One of the great things about websites is that you can start small and add things as you need them. Start out with a pamphlet-style site, then add a blog or a shop. Iterate over your app and expand gently. Use analytics to figure out what your audience wants. Then put in the development time for it.
If you start small, it'll be easier to isolate and solve issues as they appear. You'll have time to become familiar with your setup before you introduce complications.3. Not keeping (enough) backups
I'm fond of the saying, "One is none. Two is one." If you have only one copy of your data, you don't have data—you could lose everything in an instant. This goes double if your one copy is the live site. The internet is treacherous and servers go down every day. Your host will often keep backups; however, if you're on a cheap host, you should run your own backups. Cheap hosts back up partial data for short periods of time. This is to cover their butts, not yours.
A staging site shouldn't be considered a backup. The point of a staging site is to change things to see if they'll work before changing the live site. Therefore, it can't be a source of truth for your live site if something goes wrong.
You might already have backups set up, but do you have to run them manually? And how many backups are you keeping? The answers to those questions should be "no" and "at least a few months' worth." Doing backups manually is a good way to not have backups. Only keeping one or two recent backups is a good way to end up with only infected versions of your data. Then you won't be able to revert to a time before your blog advertised penis enlargement to your visitors.
Make sure to set up automatic backups and keep multiple versions. There's no excuse not to—cloud and physical storage are cheap and ubiquitous. Any CMS worth its salt will have a reliable automatic backup extension available. Any web dev worth their paycheck can set up automated backups, on or off a CMS.
Back up at least weekly, and keep at least three month's worth of them. Statistically speaking, you'll need those backups at least once, and you'll be relieved you have them.4. Not doing (regular) maintenance
Unfortunately, unlike backups, maintenance can't be completely automated. Taking care of a website requires time, discipline, and technical know-how; however, if you keep things simple, maintenance won't take much. My maintenance checklist takes about 15 minutes to complete, if I don't have to squash bugs. Even if I do, it usually doesn't take long, since I take updates in small increments.
I run maintenance on my clients' websites at least once a month. I'll run through my whole checklist if I have an emergency security patch to implement. Sometimes if things are slow, I'll run maintenance weekly. Running through my maintenance checklist is a great Monday morning task. I think of it as doing the rounds to make sure everything's OK after the weekend.
Maintenance is an important part of everyone's life. It's the key to long-term happiness. Think about what happens if you stop maintaining your body. If you stop eating or sleeping, you'll break down. Eventually you'll stop functioning altogether. If you don't maintain your website, it too will break down—but not before it sabotages your reputation by giving your visitors a frustrating or ugly experience.
Learn more in Dash Buck's tutorial, WordPress Maintenance and Troubleshooting, at LISA17, October 29-November 3 in San Francisco, California.
Comments are closed.