When you find yourself writing code that deletes directories, you need to be extraordinarily careful. It should be subject not only to extensive testing, but a design review that questions if there isn't a better way to achieve your goal because of the many ways code that runs rm -rf can go wrong.
If code like this escapes code review and testing and wacks actual customer data, firing is an appropriate response.
Are you sure, without seeing the bug? Imagine two different manifestations of the bug.
(a): Pull out first directory found in readdir("/"), system("rm -rf ${dirname}") ( in no real pseudocode).
(b) removeCacheDirs(); --> recursiveDelete(getLocalCacheDirList()); --> ReadConfig(GetUserPrefLocation(CACHE_DIR)), .... <some horribly nested mess of functionality created by 10 different programmers over as many years, where somehow the code misbehaves under a specific set of environment attributes, etc.>
Sure - (a) would be awesomely stupid, but it's probably not what happened. Oh, it might be. But (b) is more likely, and reflects as much an organizational and dev process mess as anything. And if (a) happened, you need to ask yourself how: Why was someone with so little clue allowed to implement something like this with no code review / why did it bypass code review? What's the longer-term policy and mechanism to prevent this?
When a three year old shoots someone with a gun, do you put the three year old in jail, or do you figure out how the $*! they got a gun in the first place?
When I wrote similar functionality, we had (as you mentioned) various helper functions. All of them where heavily tested and marked for extra code review if they were changed. And if you need a temp or cache dir, systems provide safe ways to create such -- eg mktemp, GetTempPath, etc.
And it's more than fair for the lead who approved the code change, and perhaps even the lead who approved the entire design to have their jobs on the line for this.
In the code I've written that deletes directories, I never call the system level delete functions directly, and instead have abstracted them away to a function with added checks to the beginning that fail/assert with big warning messages if parameters ever try to delete root or other system directories.
It's never been triggered except by my unit tests, but I'm sure glad it's there.
If code like this escapes code review and testing and wacks actual customer data, firing is an appropriate response.