I got a call from my wife this morning telling me that one of my old web-development clients had called to say they were getting an error message when trying to update part of their website. Since the function in question has been working perfectly for the better part of three years...the likely problem was obvious, particularly since this feature should have roughly one entry per week, right?
I logged in to their content-management system*, reproduced the error, opened up the mySQL database, saw that yep, there were 127 entries, changed the id field of the table from a TINYINT (8-bit) to a SMALLINT (16-bit), went back to content-management, and made sure the error was gone. Total time, 2 minutes. Except that it wasn't 2 minutes. It took 20.
Why? Because I had to search back through several years of email to find the login and password for the database. Why not just read that straight from the code? Because it would have taken even longer to find the FTP login info (buried on a laptop with a malfunctioning screen that I have with me and on a new laptop that's sitting at home right now).
So, morals of the story:
1. Unless you really have a storage issue, don't use really small field sizes even where it makes sense (e.g., there are tables in the database that have less than 10 rows, and the user has no way to add more)...because you might get in the habit and use them where it doesn't.
2. Put some real planning into where you keep old client info. Is it truly backed-up? Will you be able to get your hands on it quickly from almost anywhere?
*Am I the only one bothered by the fact that basically no client is ever bothered that I retain access to their database, webpage code, and content-management system (any one of which would allow me to do some serious damage). I've tried to tell clients how to go about changing passwords and database settings when I turned over the finished product, but once I tell them that they'll have to let me back in if they need a bug fix, they always just want to leave things as they are. Which I suppose is fine, but if there's enough staff turnover, in a few years it's possible that no one at the client will know I still have such access.
In general, I think this shows a blindspot many people have about computer security. If you ask someone at a bank, say, who has the most "trusted" person (data-security-wise) is, they're likely to say the CEO or President or some such. Of course, it's actually the database administrator or whoever sets up accounts, but he/she's just a peon and doesn't count.
