How fragile is your program?
Over the last few weeks I've had the dubious honour of debugging and creating installations for other peoples code (cringe). I'm sure anyone who has done maintenance work can tell war stories (or WTFs) about some of the horrible things that have scarred them for eternity, so I'm not going moan about that. Hell, I've even cringed at my own code! The question is: How do you stop your coding masterpiece from being scrapped by the next developer that comes along because they don't understand your code, or there are some mysterious configuration settings that nobody knows about, or it just doesn't work anymore?
I'll just assume that you understand that things like hard-coded paths and connection strings are punishable by death and nobody does that anymore, right?
Put all your configuration in one place - once you've decided where your config is going to be, stick to that place. ini files + the registry + config files + arbitrary text files + settings in a database table + isolated storage is heading straight to shady pines, do not pass GO, do not collect R200.
Zero configuration - A myth? Not necessarily...with a bit of effort it can be done. Can your application start up without any configuration? or at least start and give a meaningful indications of the missing configuration. In the case of a windows forms application you can get the user to fill in the missing values with a startup wizard or opening up the options page.
Applying configuration changes - Make sure that your application can actually respond to changes in the configuration, without having to restart the whole application.
Self Healing - One thing that has stuck in my mind is Auratius's post on SAArchitect about “Self healing” systems. I'm not sure that there is a simple way to implement it, but the first step is to anticipate the problem, and in many cases you'll find that there is a way to either prevent the error from happening, or recover gracefully. Precondition / Postcondition style programming can go a long way to identifying potential errors. You can be sure that when those clever people that created the .net framework decided to build exception handling, they intended you to create exception classes and actually write something in the catch block. I'm sure they must cringe when they see try{ ... } catch ( Exception ex) { Messagebox.Show(ex.Message); }
Users don't read error messages - In those cases when you cannot do anything but show an error message to the user, make sure it is recorded where the error actually happened, because the the only part of your eloquent finely crafted error message that they will read is “OK”, and showing a user a stack trace will make them very very nervous.
ok, I'm boring myself now, so go forth and create nice programs and be kind to animals and rhubarb fishpaste.