Video: Fired NMS employee speaks out about errant F-bomb on Chrysler Twitter account [autoblog]

Scott Bartosiewicz was fired from the ad agency NMS, which was itself fired by Chrysler.

The real problem (as usual) is one of process. Whoever thought that giving one or more people direct access to a major (or any!) client’s identity was a good idea shows an astounding amount of amateurism. I would have expected tweets to be submitted for review and approval, but hey, I’m just the guy who keeps the lights blinking in the datacenter. I don’t even have cool hair or trendy shoes.

If this were a blue-collar area, everyone would snicker at the git er done mentality, but add that hair and those shoes, it’s a software problem!  At least, in Mr. Bartosiewicz’s mind, it is.

Bottom line is, whenever I see something stupid like this happen, I’d look first for a process failure and not a broken tool.

Read the article and listen to the interview here.

Update: The podcast will not load unless you’re logged in to site.  It’s a free registration, or you can hit BugMeNot.com.

I had a nice reminder recently of why it’s good to stick to best practices when putting something shiny and new out for others to see. Something that was supposed to be easy ended up causing some furrowed brows for a bit. Luckily, it ended up being just a bump in the road thanks to some spot-on work by my creative counterpart, and some good, old-fashioned use of vi (still the handiest tool to have around, in my book).

So basically we learned a lot about the surprisingly crazy things that WordPress will do when moved without due care. Like modify your theme’s source code. And also, it was a good reminder to follow best practices when deploying an application, even when it looks like a slam dunk.

I know many of you already practice this, and it’s a bit of preaching to the choir, but hey, everyone in IT loves to talk about how things should be done, so let’s sing it together:

1. Have development, test, and production environments that are separate but identical
2. Keep developers out of test and especially production environments
3. Use the same tools and procedures for moving updates from test to development as from development to test
4. Have someone who wasn’t involved in the development do the testing
5. Have someone who was involved in the development on hand in case something goes wrong
6. Have a good text editor handy
7. Know more than you need to, just in case
8. You do have a backup of production prior to making the change, right? Right?

Now, it is often the case that you or your client may not have the resources for development, test, and production environments. But having separate environments saves you so many headaches, that I advise you to grab an old desktop system and run free virtualization software (such as VMware Server or Sun VirtualBox). If you’ve never had a formal process for doing this, it will seem like a waste of time at first, but trust me, it will save you plenty of heartburn down the road. Besides, a line about “virtualization” looks great on the resume!

Once you have separate environments, and have an app that is looking good, you can deploy it to your test environment. Try to keep the test environment as restricted as possible, since you want any changes that need to be made done in the development environment. If possible, have someone not involved in creating or configuring the app test it. A coworker, an end user, or, if you’re lucky, one of those jaded QA types. Notice that you’ll not only be testing your application, you’ll also be testing how you will be deploying the application to production.

In my experience, it’s best if the developers do not have access into your testing environment. Expect lot of complaining about this one, but you do not want developers saying, “oh, that’s not a big deal, I’ll just fix it in test,” and ruining the point of having separate development and testing environments (and usually the code repository, as well). I can’t count the number of times I have seen this cause problems.

After everything’s passed testing with flying colors (send it back to dev if it doesn’t), you’re ready to push your app out into production. Since you’ve already done the process once successfully, it should be a breeze the second (or thirteenth) time through. Pat yourself on the back and head out early to the local brewpub (after making sure that everything is working fine, of course!).

And we all know that there are times when it certainly doesn’t work fine. Which in a sense is why we’re all paid the big bucks, right? When things do go wrong, it’s best to have good resources on hand, whether it’s debugging tools or debuggers. Far too many times, I’ve seen the people who developed an application, configuration, or whatnot, walk out the door on their way to vacation about 10 minutes prior to go-live. In many situations, simply having another knowledgeable person around will help immensely. If you’re doing something specialized, like anything spelled “Oracle,” keep your DBA’s phone number handy and verify that someone is paying the licensing bills (a former employer did this to themselves six months after I left – they tried to save money by not paying for software and ended up being down for two solid weeks – genius!).

As for tools, it always pays to have a good text editor, that you’re familiar with, handy. Vi, which I mentioned before, is extremely useful. Since it’s available on basically every Unix and Linux system, it’s a good idea to have a basic knowledge. On OS X, I’ve been very happy with TextMate, which recognizes a large number of text file formats (eg, HTML, Perl, PHP, etc.). Even lowly, unloved Notepad is an effective and useful Post-It Note. Other tools that are especially helpful include tcpdump and lsof on Unix, SQLdeveloper or SQL*Plus when working with Oracle, and with Windows, keep the install CDs handy!

Then there’s you. I really encourage everyone to have a basic understanding of how different platforms work, as I have yet to see an IT shop that ran completely on a single platform. Almost everybody has some mix of Windows and Unix servers, Cisco or low-end networking hardware, a database or three, some sort of storage, and probably the phones, too. If you know the basics of how most of those things work – and especially, how they talk to one another – your life is going to be a lot easier. And again, looks great on the resume.

Finally, make sure you have a good backup before you do anything. This goes double for big, important databases that C-level execs notice when it goes down.