We've all done it, but nobody likes to admit it: You delete all files, and there's no backup. Your momentary, calm puzzlement at rm's cryptic response, and the subsequent silence of ls is followed by a tsunami of horror and disbelief as you look back through your command history to find that you accidentally added a space between "*" and the file extension. For instance:
$ rm * .o
rm: cannot remove `.o': No such file or directory
$ ls *.c
ls: *.c: No such file or directory
$ ZOMFG!!!bash: !: event not found
This only seems to happen when you've been developing nonstop for days, and the most recent backup was last weekend. It makes a good case for keeping intermediate build files in a separate directory and adding a "clean" dependency to your build configuration rather than trusting any form of the rm command to the reliability of your typing skills.
But no matter how clever your configuration, sooner or later some important files will land in the old bit bucket and said bucket will get emptied before you can do anything about it. This happened to me just last week.
I was collaborating with a client, and we were using a shared storage space to swap files back and forth. I created several test fixtures for them right in the shared space. For some reason, I didn't make copies on my local drive as I usually do. I guess I expected the client to copy them over to their permanent storage right away.
You can probably guess what happened. The client didn't get around to copying the files because they weren't ready to run the tests yet. The shared space is intended for temporary storage only, and it gets wiped about once a week -- with no backup. Friday came and left with my tests.
I'm kicking myself (and that's not easy to do) for not keeping copies of those files. I should have been aware that the shared space was not backed up and would be erased. The lost files represent about a day's work -- though writing them the second time should go faster. I feel responsible, and I'd like to make it up to the client.
What should I do?
Should I offer to go off the time clock while I recreate the tests? In other words, should I pay for that mistake? Or I could bill those hours, but then offset it with a credit so they could see exactly what I'm giving them.
Maybe I should split it with them, since it's partly their fault. After all, they knew the files were there, and they didn't make sure to get everything they needed out of the shared space before it got wiped.
Come to think of it, maybe it isn't my fault at all. Sure, it's good practice to keep copies, but am I really required to provide backup for my client? And even if it was partly my mistake, does giving them a credit for it set a dangerous precedent? If I had to pay for every bug I've ever introduced, I'd go broke in no time. A certain number of mistakes is just a fact of life in software development.
On the other hand, they are one of my best clients, and right now they have a sour taste in their mouth. Maybe a "customer appreciation credit" without attaching it to this debacle would be the right approach.
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.