No wait; actually it was daytime in the spring of 1997, but it was probably raining (I live in the Pacific Northwest). I was sitting in my office lamenting about the lack of visibility and tracking available to manage my team of support technicians. I was in charge of desktop support for a training facility with about 400 desktops. I was an aspiring developer masquerading as a Chief Petty Officer in the U.S. Navy. Our budget was tight, so I knew purchasing a ticket tracking program was out of the question, even if one existed. I decided to write my own. Several weeks later I released version 1.0 of “SSTrack”, “SS” signifying “Silent Service” which is an alias for the submarine service of which I was a member. I was very proud of the application and announced to my team that they were required to use it to enter trouble calls and to track the symptoms and resolution of the reported issues. Alas, thus begun the infamous technician revolt of ‘97.
Technician after technician called in complaining that the application didn’t work. They complained about it crashing or locking up every time they tried to enter a ticket. I, as the developer, dismissed their complaints. It was obvious that they were not using the application correctly. After all, “it worked fine on my machine!” However, faced with a mass revolt, I was forced to face the reality that my application was poorly written. Worse yet, it was untested by anyone other than me, the developer. I knew the “happy path” and made sure the application worked the way I intended, but other users of the application deviated from my “happy path,” causing multiple failures and much angst.
…So began my first journey in to the world of error handling, but more importantly, testing.
It became very clear to me that software testing was invaluable and critically important to the development and release of quality software. However, for years I struggled with ineffective software testing. As I moved inexorably toward database development, my problems increased exponentially. The data tier was virtually the “undiscovered country” of software development when it came to change management and control (and in many cases remains so). Rigid versioning and source control has become the rule for application code, but the data tier has in many cases remained the “Wild, Wild West.”
Enter Visual Studio 2010 and Team Foundation Server 2010.
Now, the almost preposterous questions – “Can I check my database in to source control?” or “Can I unit test my database?” – are both answered with a resounding “YES!”
Using TFS and Visual Studio 2010 allows me to manage the entire lifecycle of my application INCLUDING the data tier. Tracking application and database requirements and changes is now in one place, with reporting and configuration management included. It’s like database development Nirvana.