As I prepare to bundle up The Web Site to be passed onto next year’s crop of staffers, I thought it might be good to lay down some of the ideas I’ve conceived (for better or for worse) about code development in a newsroom. I’m going to go for the most important one first:
You, as a person, must not be crucial
One of the biggest temptations when you get the proverbial keys is to do really, really epic stuff. I’m guilty of it. But you should realize that if you write “business logic,” you’re failing your team because you’ve introduced a dependence on a single failure point — you. Note: If you’re not doing epic stuff, you’re doing it wrong. I just mean that you shouldn’t be putting the burden of keeping the website live on yourself. That’s crazy, and you don’t want and shouldn’t have that responsibility.
Sometimes I write about web technology and make sandwich analogies, sometimes I push buttons on a camera. Here’s some other stuff I’ve been up to.
This is why I chose WordPress and not some fancy custom content management system. I think I could write something custom and cool, but if a single line of code breaks, the whole site could (read: would) go down. If the author of said crazy code is gone (college paper = people leave a lot), that means a massive headache for your successor and downtime. I’m going to make this point about 10 times in this post.
So resist the temptation. Do not edit the core. Do not hack a crazy piece of code in that will destroy everything when someone else’s API changes. (Other people’s APIs do change, and it will break your stuff.)
To really reiterate: Do. Not. Do. It. Please.
If you’re thinking, “Man, this guy is a huge bummer,” it’s probably true.
But seriously — choose a web application platform that gives you the flexibility to do cool stuff, then …
Build tools, not infrastructure
By building tools, you’re empowering the content producers that interact with the CMS.
(If your staffers are not adding their own stories, photos, audio, slideshows, etc., revisit your workflow. They need to do it themselves.)
If those pieces of code explode, that’s sad, but it’s not going to take the entire site down.
Back it up
If our Linode VPS caught on fire right now, I should be able to pull the database dump and file archive, put it to a new server, and have it running in less than a hour.
I built the current server in 45 minutes, from entering my credit card number to having it serving pages with the theme, but I’m a pretty huge Linux geek.
Linode has a fantastic library of tutorials. The WordPress documentation is also incredible. Use them. Do not reinvent the wheel — work for and with the community to make the coolest product you can. Try not to get hung up on the nuts and bolts.
(I like Linode, but there are some really good other hosts out there. I host my personal site on Linode, which is why I went to them in a pinch.)
Figure out a backup strategy. Automate it. Test it to make sure it work. Make sure you’re back up files as well as the database.
Hacking is okay
I might get in trouble for this one, but I’m throwing it in. If you keep every project in the incubator until it’s perfect, it probably won’t ever get out. If you can cobble it together, do it. (Again, you should realize that you’re working for a professional company and everything that’s online is not just for fun — you’re a real, credible publishing platform. You cannot afford to damage that.) But if you can throw some Yahoo Pipes, Google Maps and jQuery at it to get it to work, do it. Building the perfect back-end interface might not be the best use of the coding monkey’s time. Release early, release often.
Ask people for feedback
Especially newsroom employees. It’s important for people to feel invested in the project. After all, they’re the ones you’re asking to go above and beyond. But also ask users, professional staff, ad reps, roommates, random students, etc. Nobody can think well in a vacuum, and web architecture is rarely something that can be produced without a lot of conversation and iteration.
Share your progress
Create internal resources and make them public. Sharing is cool. Transparency is cool.
That’s all I got for now. Like everything involving the Internet: to be continued.
(I just got the infobox stuff kind of working. The code looks like this, but without the space between the <�‘s and [‘s so they don’t render.)
[ infobox title="Oh, hello!" query="author_name=ivong&posts_per_page=5" ]
< img width="200" src="http://www.dailyemerald.com/wp-content/uploads/2011/05/ivar_vong_mug.jpg" style="margin-top:-13px" >< /img >
Sometimes I write about web technology and make sandwich analogies, sometimes I push buttons on a camera. Here's some other stuff I've been up to.[ /infobox ]
