This weekend, I had the unique opportunity to donate some time to a worthwhile charity organization. Through the efforts of the Dallas-area .NET user group community (and specifically, Toi Wright), Microsoft, BravoTech and a number of other vendors, the first annual We Are Microsoft Charity Challenge was born in a flurry of activity over the last three days. This event was held in Dallas and matched up 100 or so developers with 18 charities in need of development services.

I was placed on a team assisting SER Child Development Center with developing a new website . This organization aids low-income families by providing low-cost child care and education, as well as adult education and career development services. From the outset, the organization staff were prepared and readily available; they arrived at the kickoff with design ideas, a packet of information as well as a USB drive full of electronic content and photos. Juan Torres, the CEO and President, and Dr. Carol Johnson-Gerendas, director of the center, were very enthusiastic about this project, volunteering to stay with us for as long as necessary to bring us up to speed on their needs. These two were gracious and appreciative, and made us feel like our efforts really will make a difference.

My team initially consisted of four people, but we lost one member to the flu on Friday. The other remaining members were Ryan Magnusson, a developer working for Wal-Mart in Arkansas (yes, he actually drove in for the weekend) and Raymond Sanchez, a web developer local to the Dallas area. After reviewing the charity's business model and website requirements, we opted to use a SubSonic starter kit for our project. This allowed us to quickly roll out the base application (essentially a CMS) and gave us a framework on which we could develop a couple of requested custom components. I took on the role of project lead as well as writing the custom components, the latter of which was very gratifying since I don't get to write as much code as I used to.

Like all software projects, we had a few glitches. The most frustrating issue was the web space provided for the event had a number of issues which were not resolved until the last day of the event.  This left us with the unfortunate choice to leave their existing site in place (having run the demo from my laptop, where the code resides) until we resolve the issues with their web host. We also had a phantom error in SubSonic that slowed us down for a few hours. Since we only had 48 hours in which to work, sleep was simply an afterthought (in fact, one of the guys actually pitched a tent in the break room and slept on site). But the food was good and plentiful, they kept us filled up with caffiene, and the facilities were spacious.

 We also had the opportunity to be interviewed by some of the guys from GeeksWithBlogs.net, which was published as a podcast [listen here] .  This was my first - and hopefully not the last - podcast interview.

All things considered, the project was a success; when we met with the charity staff at the wrap-up meeting on Sunday, they were highly impressed with the product. Though we didn't win any awards, I'm confident that we have created a solid application on which they can promote their charity for many years to come.

The We Are Microsoft event was billed as a "first annual", suggesting that this will be an ongoing gig. It was suggested that perhaps other user groups will follow suit and host their own WAM event.  As for me, I'll be first in line to participate again next year. And maybe I'll bring my tent....

It seems that I keep inheriting old systems that provide a singular, albeit mission critical, function to their owners. In the majority of these cases, I have encountered numerous small applications that were designed to run in a standalone environment to solve a very narrow problem or set of problems. The person who supports the application - which is very often the same person that wrote the code behind it - eventually departs the company without documenting his/her work. Somehow these database apps keep chugging along for months or years until one day a tragedy occurs - like a folder being renamed or a mapped drive being deleted. My phone rings, and I step out of my database analyst role and into my Sherlock Holmes coat.

I'm sure you've all been there. A problem that should take you 30 minutes to fix actually costs you two days because you have to reverse engineer the environment to figure out what the programmer or database designer was thinking. These kind of things get me more irritated than a cowboy without a saddle on a hot summer day.

It's not just for the sake of others that you document. I can't tell you how many times I've looked over some of my own handiwork and wondered what I had been thinking when I designed a feature or configured a particular database object. With few exceptions, I almost always fall back on my documentation at some point, even for the most trivial of things.

So I put out the call to all of my fellow IT folks, database analysts/programmers/sysadmins/[insert your job role here]. Document, document, document. Even if you're sure no one will ever need it, document. If you are creating an ETL database that you plan to delete in 90 days, document. If you write a function that's more than three lines long, document. Your successors will thank you for it. You might even save your own job some day!