Picking the right tool for the job

An opportunity came my way a while back to be the treasurer of my son's soccer team. Being the geek I am I immediately thought I would create a nice WPF application that would allow me to manage all the information I needed (player information, who the parents are for the player). Well, needless to say about 5 months have passed since I took on this new responsibility and I have already hit analysis paralysis. I am currently still using an Excel spreadsheet to manage the information and I am far from having anything I wanted in order to do this job. So, re-evaluting my toolset, I decided to give Access 2010 TP a shot to see what was available there. I did some Access work when I was still in college for a start up company, as well as for an individual who was running as a state senator here in Washington in order to keep track of her campaign information, but it has been forever since I have looked at it (in all honesty, I had written it off as not being a real tool or database platform to use, the Business guys who aren't smart enough to use a real database and programming language use Access, no way was I going to stoop to that level). Well, here I am, shoving as much crow into my mouth as can fit, because literaly after only 30 minutes, I have an application doing 90% of what I want it to do (only have reporting left) and that 30 minutes includes loading the system with data as well. So, if I have learned nothing else, I have learned putting my programming aside and using the right tool for the right job, really does come in handy at times. No, I am not going to go out and write my next enterprise application for my company using Access, but for what I needed to get done, this was definately the right tool for the job. My blog engine is a completely different story and worthy of a post all on its own (which will hopefully be coming shortly).