The design and implementation of the purely theoretical "self destruct" button

I had an Adobe Flash instructor in college who told me a story about getting bored at work. He had some downtime and was looking for a way to pass the time. While looking at some Flash code, he discovered that if you created an executable file with a couple of lines of code you could create a program that would perpetually reboot the users computer. So, armed with his new found knowledge, that's exactly what he did and promptly asked one of his friends to try out this new program he created. My response was, “You created a self destruct button.”

Now, he did this just for fun. Just like I'm asking this question just for fun.

Ever since, and quite often, when I'm working with developers I ask them if they included a self destruct button. I will then get one of two responses, either a blank stare or a simple "No". So I'm convinced the only people I can turn to are UX professionals. Which brings me to my question, which I'll phrase from a UX standpoint.

What user scenario(s) could prompt the inclusion of self destruct button? How would you as a UX professional go about designing/implementing the self destruct button? Finally, and most importantly, what would it do? If you wanted to take it a step farther, how would you calculate conversions/success?

Remember this is purely theoretical and just for fun, so the answers can follow suit, but they should still have some basis in reality (just a little is good).

If we use the story as an example, the scenario that prompted the self destruct button was a developer with too much time on his hands. The design process was simple: create an executable with a line of code. We all know by this point what the executable file did. If you're curious, according to the story the implementation was a complete success and rebooted the machine over a 100 times before being unplugged and summoning IT. So, the 100 reboots would be the conversions and the calling of IT would be the success metric.