I was pointed to an article by Marcus J. Ranum on software patching entitled "What Sun Tzu Would Say". It is a great read where Marcus argues that patching is a fad caused by a 90's software marketing drive that resulted in crappy software that you don't need being deployed. He has some advice:

• Run software that does not suck
• Absolutely minimize Internet-facing services

My response to his article is simply: it isn't a dichotomy. The entire point of defense in depth is using multiple strategies. All his advice is great, but it can, and must be done in conjuction with patching. I agree that the hoopla over patching has been over-hyped, but whatever software you run, there will always be holes that need patching. Sure, you can minimise those holes with careful mitigation strategies of which (my rewrite of Marcus' list):

• Run mature, standard software
• Minimise exposed services
• Use the right tool for the job

all are, but you can't hope to get away with never patching a system. Marcus talks about how he runs an OpenBSD and Solaris server he never needs to patch. Lets have a look shall we:

• OpenBSD vulnerabilities
• Solaris vulnerabilities

Even if your mitigation strategies ensure that all of those vulnerabilities don't affect you, you still need to carefully review each new vulnerability to see if it does, because there is no guarantee that it won't. If it does affect you badley enough and there are no appropriate workarounds, then you need to patch it: test the patch and deploy it. That sounds like a patch management policy to me, we are just arguing about how often you will end up at the last steps.