How best to make buggy code perfect? And no it isn't by going after and fixing the bugs. It's a new methodology for the 21st century.

I had a big problem with Vista - Windows Explorer kept on crashing and I had to manually stop it and restart it. The problem seemed to go away when I moved to Windows 7 thus proving the preconception that the new OS was more stable than Vista.

However, I began to notice that a message I had never seen before had started to appear. It said:

"Explorer has stopped working - restarting Explorer"

Then I realised that it wasn't necessary to improve the quality of software to give the impression that the quality had gone up.

This new approach is in the vanguard of a range of new 21st century techniques for dealing with bugs at a much lower cost and almost no effort.

All you have to do to make your crashy application more stable is to dump its state at regular intervals. Don't make the state information too detailed or you might just persist the cause of the problem as well as the useful part of the state.

As long as you save the state often enough and reliably enough then all you have to do is detect a crash - although why the same effort couldn't have been put into making the application reliable is another question,

You can do this quite easily using a monitoring and status application that, if necessary, runs as a separate process so as not to be dragged down by your less than well-crafted application. The status application simply notices when the monitored application goes unresponsive for a time, kills its process, starts a new copy using the saved status data to restore it to a point were the user doesn't regard the incident as a disaster.

The scheme isn't in itself something to be decried. In fact it is a very sensible approach to implementing a robust application that is less prone to hardware problems and rare failure modes.

When it becomes a problem is when it is applied as a band-aid to make low quality code look a little more like high quality code. Used in this way it is a reprehensible tactic.

Now consider the fact that IE 8 often fails with a message something like:

After this IE does indeed restart and mostly manages to reopen all of the web pages that were present before the crash. On my own machine this happens quite often but, of course, it could be that my machine is just a problem in its own right. It could be, as Microsoft say many times, that I've just got the wrong add-ins installed and these are making the application crash.

This brings me to my second great innovation. Make sure that you application has add-ins. Add-ins are great. They not only mean that your application can be extended by third parties it also means that you can always say that your application crashes because of a rogue third party add-in.

You can also give your users lots of helpful support telling them how to remove an add-in and its surprising how often this makes them go away even if removing an add-in doesn't actually solve the problem.

So make your application perfect without very much effort and certainly without finding any more bugs you need to make it detect a crash and gracefully restart and make sure you get lots of third party add-ins.

Of course if your application is a Rich Internet Application you don't have to do either of these things because you can always blame it on the use of the wrong browser.

Just make sure you never add the "best viewed in X" banner anywhere so that you never have to prove such a wild statement. 

All we need now is a name for this new approach - 

what about cover-up and pass-the-buck programming.

<ASIN:0814474578>

<ASIN:1593271743>

<ASIN:0321374460>

<ASIN:0321578899>

<ASIN:0123745152>

<ASIN:0130653942>

<ASIN:1402055390>

<ASIN:193435628X>