It had been a busy an productive month and a half. I’ll start off by pointing to the first two prototypes delivered by group on Thursday February 25 2010:

Quickly, you are looking at is a simulation of a specific problems what can occur within a database system. The problem is then identified using the SQL monitoring functionality available within DB2 and then that mass of information refined into some simple prototype indicators.

The goal of this project is to build a system where a problem can be simulated within a database in a safe non production environment to teach and show a database administrator how to identify these problems in the real world, a flight sim for db2. The above are admittedly unpolished, but everything needed for the project present. What is seen in these videos is descriptively simple, I would like to highlight a few thing. First off writing a bad query (piece of code), yes any one can do it, and more do then we would probably like, but to exploit behavior and trigger only a specific effect is not an easy task, in my experience it is significant harder then writing an optimized query because it requires that you have a full understanding of the underlying system. Next, identifying where in DB2’s numerous monitoring tables and unique lingo, is not a simple task, it takes most interns and new employees 2+ weeks to even get to a point of functioning. I can tell you it is vary frustrating until you get over that hump and look back on what you have learned and the group had done wonderfully. As for the ugly dials, yha they are ugly, but that is only cosmetics, the underlying functionality is there and I know better ones are coming.

Overall, I am extremely happy with the work that has been delivered so far. The team is getting more comfortable with each other and more comfortable with not knowing and asking question. We work in a businesses that has so many facets, so much knowledge that it is impossible to know everything and you are not expected to, (wiki’s, books, forums, were all invented for a reason). You are expected to say ‘I don’t know’, ‘I need help’ and that is one of the greats things of working within a big company. Often if I have a problem, I can just find someone who has experience in the area or simply talk to the person who wrote it in the first place and ask them directly for help. People should never hesitate to ask others for help, the likelihood is that so time in the future someone will need ask you for help. Time is valuable, if a question can save you time, it is worth asking.

An observation from my experience and I am curious to hear back from other groups on there experiences. I know that the group found the initial semi imposed two phone conference meetings a week a bit to much, but I have always found it critical when working with a distributed group to ensure a constant line of communication. I has been reduced down to a phone conference and a checkup using Skype chat a week which seem to have settled into a nice rhythm. Within the group and even in IBM, voice communication can be difficult for people who’s native tongue is not the same, or for those with different accents. Not only can it be difficult it can be down right intimidating when you are outnumbered in the call, but often it is not meant to be. Unless you speak up they can only make assumption, and they are always worse then the truth. There are other forms of communication, with this group spiting the meeting between a call and chat session has, without directly realizing it, I think dealt with this potential problem quite well.