Learning and Fixing our Bugs

I had a particularly nasty issue assigned to me a week or two ago. It's one of those bugs that I spent so much time and effort on that it was difficult to enjoy my evenings and weekend. It was nasty for a variety of reasons.

First, it involved a program component which was originally written by a developer who had already decided he would no longer work for the company, but decided he'd finish this component. As you can imagine the code is in horrible shape. Few people have any knowledge of this component, and none of those who do understand the entire system.

Second, this component could be considered an entire software solution in its own right. The size of the project is large enough that it is often installed on its own machine in production.

Third, this component was installed in an environment in the testing environment which had taken 6 weeks to setup (normally, just a few days is required).

Fourth, the error message was one that had occurred before, and in most cases, pointed to some particular setting being incorrect. Thus, it made it very difficult to rule out environmental issues.

Finally, this component is not used by one software team, but three. Since all three teams use the same component, no one “owns” the component. However, there are “satellite” assemblies of this component which each of the three teams provide on their own.

Because of the third and fourth reasons (similar errors pointing to environment issues), I spent a good amount of time traveling down that path. In the end, it proved to be a very complicated issue. There were multiple reasons for the errors. Most of the errors could be tracked down to the final reason, no one owning the software component. Due to this fact, code for this component was not delivered correctly, because of the satellite assemblies.

I learned a couple valuable lessons from this error though. First, I had great difficulty recreating the error due to a poor setup on my development machine and I can never let that happen. While I normally detest debugging, debugging this component is absolutely essential, for the size of the project and the poor state of the code is to much for one developer to grasp at one time.

Second, and more importantly, I learned it is a VERY bad idea to have a large internal component which is used by several teams, but no one team is responsible for maintaining. In hindsight, this is obvious, and probably rarely happens in other companies (if does in yours, I'd like to know).

While I could have done a much better job in handling this error and I could have solved it in a much quicker fashion, I have at least taken a couple things away from my mistakes, and my boss has recognized that this component needs to be developed by one team, and one team only.

So, recognize that mistakes will happen, but always learn from them, especially in the field of Development.

The Second Browser War

With Mozilla's Firefox going strong, currently with roughly a 15% market share vs. Internet Explorer's 78% (source: http://marketshare.hitslink.com/report.aspx?qprid=0), the Second Browser War has begun. For those of you who don't recall the first browser war, or who haven't been reading many articles on the recent browser war, here's a short recap for you:

The first browser war started in the mid 1990s, where Netscape Navigator was the dominant browser of choice. Microsoft introduced Internet Explorer, and thanks to its distribution with new PCs, it eventually became the dominant browser of choice. Netscape Navigator (later Netscape Communicator) was eventually defeated, largely due to issues with distribution and the fee structure (while Internet Explorer was essentially 'free', one had to pay for Netscape's browser up to a certain point). (For more, check out http://en.wikipedia.org/wiki/Browser_wars).

Mozilla's Firefox, however, has a few advantageous over Netscape Navigator. Firstly, today, most people have high-speed Internet access, allowing them to easily download a new browser if they choose. Second, Firefox is completely free (and open source), eliminating two of Netscape Navigators problems. However, there's still the giant elephant in the room, and that's the fact that nearly all PCs made today ship with Internet Explorer installed, while very few are shipped with Firefox installed.

Numerous security threats, and in many cases, better performance is still not enough for people to switch browsers. What is needed to force users over to Firefox would be some feature that users had to have. But, whatever feature is added, you can be sure that Microsoft will add the same feature to Internet Explorer in its next release. We've seen this before with tabbed browsing. IE7 introduced tabbed browsing, but it has been in existence in some form in Firefox for quite some time.

Judging from the low ratio of Firefox to Internet Explorer users (1 to 5), things aren't progressing quickly for Firefox. But, consider what internal web applications you use at your place of employment. Are you able to use Firefox, or are you forced to use Internet Explorer? If you work on web applications, do you focus your attention on Internet Explorer, or on Firefox? If you work at a place like I work, Firefox is a word not muttered, nor does one care about it. Where I work, all of our internal apps run on Internet Explorer, and unless something changes, we never will. I'm sure the same applies to internal applications at many companies.

What does this all mean? Well, most people use Internet Explorer at work. And because of this, they're probably not interested in learning to use a second browser for home. In my opinion, until Firefox breaks through into the corporate world, it will not be able to gain a much larger market share. And until that happens, we will have a Cold Browser War, instead of a full blown browser war, like the one that we witnessed at the dawn of the internet age.

SQL Server 2005 Management Studio File Locations

Why is it that each new program that comes along must have a different location to save its files? What's worse is when a new version of a program requires a different location. The first that comes to mind is Visual Studio 2003 and Visual Studio 2005. Each create a new folder in the users 'My Documents' directory. I recently had to install SQL Server 2005 Management Studio, which, by default, wants to save scripts to “My Documents\SQL Server Management Studio\Projects”

Now, I'm not a Database Engineer, but I have accumulated two dozen SQL scripts for various database tasks and already have a location where I've saved these scripts. There's two options, move the files to the new location (My Documents\SQL Server Management Studio\Projects), or modify the the settings to change where the files are saved.

I recommend the first option, because after considerable effort, I was not able to find all the settings to change where the files are saved.

The SQL Server Management Studio file locations can be customized through the registry. By navigating to “HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\90\Tools\Shell” in the registry, there are several keys which point to the folder “My Documents\SQL Server Management Studio\Projects”. The main key to change would be “DefaultFileOpenLocation”. Unfortunately, this only controls the directory that the program looks at when clicking 'Open File'. After over an hour of research, I wasn't able to find a setting to change which would force the application to change where it saves SQL files. So, while a user can control where to open files by default, the user cannot control where those files are saved by default.

I think the most frustrating thing about this, is how close I got to getting the application into doing what I want. To have that taken away from me because the program is designed to use settings defined in the registry AND hard coded into the system. BUT, the settings sprawl does not end there, in the “My Documents\SQL Server Management Studio\” you'll notice a folder labeled “Settings” which contains even more settings, this time in a .config file. This file also defines file locations, as well as several other application settings.

I initially intended this to be a how-to on how to configure SQL Server Management Studio to point to the location of YOUR choosing. Unfortunately, the application had other plans and this has turned into another example of a program implemented poorly.