tl;dr - I restart everything I can, all the time, because I don't trust computers, software, hardware, firmware or networking.

This is a blog post I've been wanting to write for a long time, probably about a year or so, give or take a few months. I've been in software development for almost 10 years now (and consulting for most of that), and as such I've seen a lot of crazy stuff. Things that don't make sense, things that are just plain hilarious (once I've calmed down from unspeakable rage), and things that defy the very fabric of what we consider reality. There's a reason one of my all-time favourite blog posts is called 'Programming Sucks'. So at this point you might be thinking "oh, this is just another jaded software developer ranting about about software". Congratulations, that's exactly what this post is! :D Basically, venting is good for the soul, and this post represents my attempt at venting my anger and frustration in a semi-lighthearted manner. So... I'm going to say something I've been wanting to say for the longest time...

I don't trust computers. At all.

Ahhh, that certainly is theraputic. Now you might be thinking "Adam, you're in software development! You look and stare at computers all day every day, and bash on the keyboard eventually hoping something will work!". Yes... yes, right you are! But bear with me, dear reader. There is a method to my madness.

Its possible at this point, you've looked at the title, and wondering if I've made some sort of mistake, I haven't. For any computer or server with IIS installed, iisreset is the command that restarts IIS. In web development, a lot of the time I'm having to deal with IIS and its various shenanigans, so the choice of iisreset as the title of this blog post is a very deliberate choice.

IIS has what is called 'Application Pools', that serve as containers for the process that your website is running under, and for the most part, they work very well. If you've made a particular type of change to your website, and you deploy it, all you need to (theoretically) do is recycle the Application Pool and ta-da! The server reloads the fresh files/DLLs into memory and your websites are now happily churning along on the latest incarnation of your website.

That is, until, things go horribly wrong.

I've been burnt many, many times by servers/computers that don't necessarily behave as they should. One of the most frustrating things that happens in the above situation is for, whatever reason, something goes wrong in the internals of IIS and recycling the Application Pool doesnt have quite the effect you'd expect and you're left scratching your head for several hours while you troubleshoot various things, with a slow descent into madness.

For developers (for me at least), there are few things worse than simple things that should work, but don't. Which is why my default, when changing anything to do with a website, is to restart IIS itself, through the glories of iisreset, as opposed to relying on the Application Pool to recycle properly (keep in mind, I'm talking mostly local development with this post). This will flush out whatever garbage has been caught on the inner gears of IIS internals, and usually this avoids any head-banging troubleshooting.

Now most developers at this point will be laughing at me, and I completely understand why. Most of the time, recycling the Application Pool works perfectly well, and restarting IIS just for something simple is definitely a sledgehammer meets nail sort of thing. But they haven't seen the things I've seen. Restarting IIS, for most of the situations I've dealt with so far, is a fairly quick process. That extra second I use in restarting IIS itself, rather than relying on the Application Pool, saves me from those times where I spend half a day scratching my head trying to figure out what's gone wrong, when nothing has actually gone wrong, its just IIS having a moment. I don't trust Application Pools. I don't trust IIS. I will use whatever tools are at my disposal to minimise the risk of something completely damn crazy ruining my day.

BizTalk is another platform where this sort of mentality can pay off in spades. BizTalk has a habit of holding things from the GAC in memory, so if you're not careful you can get into a lot of trouble with a rogue DLL hanging around where you didn't expect, or when BizTalk itself is having a moment. For most things when I'm dealing with BizTalk I will restart the Host Instance itself after making a change, because I don't trust BizTalk. And I'd rather take the extra 3 seconds restarting the Host Instance than having to deal with the black box that is BizTalk (and I'm fairly sure any BizTalk dev reading this right now will be emphatically nodding yes at the screen). Once, somehow the underlying XML of an orchestration shape got corrupted to the point where it completely broke the subscription it was listening for... The fix? Delete the shape, and re-add it. Bam. Fixed. This is why I don't trust BizTalk.

This is why, for general development purposes, I take the attitude of:

Restart everything you can, all the time. Nothing is sacred.

Heck, if I see some weird things happening when I'm doing development, I will restart my damn PC at the drop of a hat. I don't trust my PC.

If it's a quick process to restart whatever you're dealing with, and strange things are happening, restart everything you can. Even if nothing eventuates from it, and nothing magically fixes itself, at the very least you can rule out some of the crazier stuff that can happen in the world of software development.

There's a reason this quote resonates so strongly (and hilariously) in the IT world.

If you've made it this far, dear reader, I salute you. Thankyou for taking the time to listen to my ranting :)

Update: A colleague gave me some very valuable feedback, saying that I was potentially advocating this sort of method on a production environment. After re-reading the post I could see his point, so I thought I'd jump back in and clarify: This is definitely not the recommended way of dealing with production issues. You should have sufficient instrumentation, logging and monitoring in place to figure out what's going if you're seeing strange things. Restarting a production server should be the very, very, very last thing you attempt in fixing issues. Thar be Dragons!