It Works on My Machine!

How many times have you heard this one? Or it might have been stated "It works in my Browser". It doesn't matter.


Wannabe Code Monkeys do this all the time. When you are developing code on your machine, you have certain settings and an environment that may have certain attributes or settings that will not always be the same in the target environment - the user's machine, or a webserver.

One of the newest offenses is where developers create web sites using the WebSite project model in Visual Studio 2005, using the built-in Development Web Server. There are minor inconsistencies in behavior between this ASP.NET webserver and the real IIS. In fact, if you develop on IIS in Windows XP, I bet you use an IIS application ( a VRoot that is below the actual root of the site - since Windows XP IIS only offers "one" web site), even though you are developing a full site that will usually be at the web root of an IP address on the target production server. Again, the behavior will not always be the same. You have session, cookies, settings, relative paths and more, some of which may not match up or behave exactly the same way they did on your developer machine setup. You could have a web.config file in a higher folder with HttpModule settings that cause your application to blow up because you didn't think the settings would be inherited.

One of the marks of the professional developer is to keep this in mind and perform sufficient testing - including enlisting friends or co-workers to help - in order to determine without doubt that your creation will indeed work the way you intended it to work -- in production.


I remember the first time I uploaded a web page that had image tags in it. When I looked at the page from the webserver, no images. Silly me - I had FILE:/// references in there. Of course it worked "on my machine!". Fortunately, I was still around to fix it - I hadn't left for home yet. Problem? The only place I had ever tested it from was my development machine, where all the image tags seemed to work just fine!

My point: Never "assume" that because everything works fine on your machine, that it will in deployment; test thoroughly to be sure. If it's a web application, test it from other people's machines and with different browsers / versions. And do a "Smoke Test". A smoke test is a set of steps that a user must go through which ensure that all the major functions and features of an application are working as designed. Where I come from, nothing is in "production" and "done" until it has passed a comprehensive smoke test. Above all: Stay tuned to station WDTA. When you are going to make a change to an application, always stop and ask yourself first: "What Does This Affect?".

"In Production" is the worst possible place to have to test software or web sites. Unfortunately, a significant percentage of outfits do just that. They don't have a "test" environment, they don't have a QA department, and they don't have a testing regimen. They don't know what a "smoke test" is. Contractors come and go, they push untested stuff into production, and there's nobody in control to ensure quality. This results in embarrassments and a lot of extra lost time that costs money. And if you own the company, shame on you, because you just threw some of your profits down the toilet, and you may have lost credibility with your customer(s).

Testing your "stuff" in production means that it will be your users and clients who find the boo-boo's for you. At best, that's extremely unprofessional.

Are you sure that's what you want? Test your stuff. Test it well. Sleep better.