« Why Microsoft has so few excellent products... | Main | Not a preface »

So, with Daring Fireball and Jeffrey Zeldman offering update tips, and since I'm busy preparing for my session at Macworld Conference and Expo in San Francisco, I figured I'd do a little "me too" here and offer my tips on updating. Again, I'm an IT geek, so my tips probably aren't what most home users are looking for. Nonetheless, they work well for me.

(Yes, I actually do get nervous about my sessions at Macworld. The audience there tends to be really sharp. As in the very charming older German gentleman who kept me hopping with very in-depth questions about RF design issues during a session I did on Airport networks. He introduced himself as a retired Ph.D/Professor of Electrical Engineering. He said, "You are a very intelligent young man, I enjoyed your session a lot." I felt like I had gotten a gold star. But yeah, I always assume my audience is smarter than I am, 'cause they usually are.)

1. Have your users run clean systems. I mean as in no startup items that are not mission - critical, and required. AKA: No haxies. If you have a user who says they need a particular haxie, find out why. Odds favor that it's a behavior held over from Mac OS 9, and they don't know that they can replicate it closer than they think in Mac OS X without diddling the system. I find that showing how, in Panther, the Classic Menubar Widget holds a link to the Mac OS 9 Apple Menu solves a lot of those needs. Basically, learn how the UI of Mac OS X works, and help your users find ways to use it cleanly. They'll appreciate it in the long run when they don't have to deal with the complications that OS Hacks cause. Before you fire up the flames, I am one with Rich Siegel of Bare Bones Software on this. It is the person or company developing the hack's sole responsibility to ensure flawless compatibility with OS and Applications. Period. The hack is breaking the rules, it therefore has to be better than everyone else. It is not up to the user to keep track of what applications work with what hack, and it is not the application developer's job to test the code of a hack. The "our hacks find errors" line is just sophistry.


2. Make sure you need the update. This sounds obvious, but sometimes people forget to think about this. Read the notes on the release. Is there something in here you need? Since most updates contain security fixes the answer is usually yes, but knowing what is generally affected by the update is a good thing.


3. Have a good backup. Another obvious one, but I see it ignored a lot.


4. If you are dependent on certain software or hardware to get your work done, contact those vendors before you update. I see this one over and over. Oh woe is me, I updated and now <mission critical thing> won't work, and it's because the update is broken! DAMN YOU APPLE!!! Well, no, it's your own silly fault for updating production boxes without checking to make sure that all your mission - critical stuff works. Take a week or two if need be and contact the people who make what you need to do work with. Better to wait a week and save a lot of pain the hope for the best and be wrong, right?


5. If you have to update multiple computers, do them in batches. If there's something about your standard setup that causes the update to go south, this is a way to detect it without having to deal with that problem on hundreds of machines. So do the update in small groups, so you can keep a better handle on any problems that might crop up.


6. Stage the updates. Do a group, wait, do another group, wait. If different groups have different configs, then this is almost a necessity. Just because the receptionist's Mac updated okay does NOT mean you should use that as a baseline for updating your RIP or your render farm.


7. Don't take every error report as gospel. This could surprise you, but sometimes, people really don't know what the hell they're on about when they point the finger of doom at an update. Usually, the I applied the update and my house blew up reports are ones you want to blow off. Stuff that's driver - related that you don't use, don't worry about it.


8. If you can, run a test machine with the update. Not for application functionality, as, unless you have a very large network/IT Department, it's hard to really test stuff thoroughly. Rather, just see if it breaks on its own. If it does, this is a sign that you want to wait a bit before widespread application of the update.


9. Document each update, with the date applied, machines applied, etc. This can be a lifesaver. I use an internal Moveable Type blog, as that way, I can get some nicer features with it. It lets me easily check to see what I've done to change things lately, which can make things a lot easier to troubleshoot.


10. Finally, even if things do blow up, don't panic. If you've been careful, regardless of how you have been careful, you should be able to get the machine back to functional status within a couple of hours at worst.

Sorry if none of these are all that innovative, but I find that attention to the basics serves me well far more often than trying to be leading/bleeding edge about it.

Comments