The other night I got a call from a DBA on my team. He was trying to respond to some problems our users were having in a new database. This DBA had some ideas about what was causing the problem. But he could not determine the source for sure. He had a lot of questions for me.
The next day I responded to his questions. My response also went to all kinds of people in the customer organization. That's when I started getting all kinds of emails and phone calls. Then my sponsor in the customer organization called me up and started asking me whether some of the things he was talking about were the cause of the problem.
That is when I realized we were in trouble. We were not going about this in the right way. I had to be abrupt with my customer. I told him that we just needed to assign this problem to a developer. The developer could figure out for certain what the problem is. We were wasting a lot of time that development does not have chasing down theories and answering questions that have nothing to do with the problem at hand.
The bad news is that the problem got assigned to me. However once I was on a mission to solve the problem, I was able to concentrate on and zoom in on the source. I did not have to educate any users. I also did not need to explain a lot of the system to new users, or trace down false leads by smart people who just don't know the system well enough. The fix will go out in our next release. I learned a valuable lesson. Don't contribute to bad processes for problem resolution. It will only be a total waste of time.
Backtrack Linux - Backtrack is a Linux distribution based off Ubuntu. It is used for penetration testing and forensics. The distro was a combination of WHAX and Auditor. It...