There was another high priority problem reported by our customers. I thought I was safe. The problem was obviously in a part of the system I don't work on. The team had a conference call to talk about this problem.
I should have know I was getting set up when the team lead responsible for the problematic part of the system started saying this was not his problem. I fell for the bait. That's when I did some research to prove it was in that part of the system.
Next I alerted management to the fact that the developer who manned this specific program actually left the company. I advised them to appoint a new developer to be responsible. Next thing I know, I am in another conference call to work out how we were going to fix this problem.
Initially they were talking crazy about the fix being done in a day or two. I told them no way. Next thing I know, I got signed up to set up the data and do the testing for the fix. They actually somehow got the guy who left the company to develop the fix. Dang. The testing is the hard part of this problem. I should have volunteered to do the fix. Ok. I helped shape the rollout schedule for the fix.
Now to meet the schedule I was going to have to do some weekend work. That was not optimal for me, but I was going to do it. Then I get a call from a manager saying the customer wants the fix even earlier. That's when I knew I had it all wrong and I was being set up. After some heated debate, my original schedule was accepted. In the future, I got to do Dilbert style and pad the heck out of my estimates.
Mysterious Double Instance Hampering Performance - I study the existing code base. Confer with a colleague. Then I determine the optimal plan to change the functionality to load only a slice of all the dat...