Schedule Fail

I had a big problem to solve at work. That's okay. Solving problems is my job. I cranked out the old estimation spreadsheet. It would take a normal developer four days to complte the task. I said it would take me four days. Now I could do it faster. But I know my work. People are always taking up my time, and taking me off the main task at hand. Sure enough, I barely finished up the task in four days.

The next big task had a short turn around. I was working hard to meet a deadline. I told my team lead that I could not take on any other work. Then I got the call back. The managers said the extra work was the priority. I shifted gears, generated another estimate, and said how long it would take. Then I got down to business.

As I am scrambling to stay focused and make up time to beat my estimate, I get an email from a manager berating me. He said we were going to miss a deadline promised to a customer because of my negligence. WTF? I fired back an email stating that we needed a meeting pronto. Somebody had their facts mixed up. I have become really good at estimation. I never miss my estimates, even when everything goes wrong.

I get a response immediately. No need for a meeting. The manager backed off. I responded, carbon copying everyone who was in the first email. If anyone even remotely thought I was the cause of a delay, we needed to meet. I never heard back from anyone.

I can guess what the situation was. Somebody made some promises without knowing the true estimate of the work. Either that, or they did not take into account when the task started. All standard fare. Then they made a mistake. They tried to blame me. Nice try guy.

Now I don't care if someone tries to badmouth me to the customer. And I don't care if you lie to yourself, or to someone else. Just don't expect to send out an accusation to me and not be called out for your BS. I just won't stand for it. Anyone who is competant should not stand for it either.

When in Doubt, Reboot

I had some crucial data correction scripts to write. The deadline was tight. People kept trying to get me off task. But I completed coding in time. I went to check my code into source control, and the tool froze. I tried again. No luck. After a few hours of messing with it, I gave up.

Other people on the team had the same problem. That was no good. It was a global problem. Some other people tried late through the night, and even the next day. They were unsuccessful. I got a message from the team responsible for the source code control. They recommend we clear up space on our C: drive and reboot out machines.

Now I can understand that a reboot might correct a single user problem. But this was a global problem. I did reboot my machine for grins. Of course that did not solve the root cause. Now they are rebooting servers to hope it fixes the problems. I suspect we are going to be dealing with this problem for the long haul.

All in the Positioning

The customer detected some unusual data conditions while testing out some new functionality in our system. Our test team was tasked with trying to replicate this behavior. Turns out they glossed over testing this function. Might have been due to a lack of time or insight. They were a bit green.

The testers could not replicate the exact behavior from the customer. They could also not make the system as they expected. They asked me for some help. I got similar results as them. We were at a loss. Then I figured we could stop trying to replicate the issue from the customer. Instead we could try to figure out what was going wrong.

We found some data. But it seemed to be chopped off at the end. Some other data was just all garbled up beyond recognition. The data getting truncated came from a file that was SQL*Loaded. I figured a truncation might be due to wrong positioning in the input file.

I researched the record layout documented in the design. Sure enough, the testers were putting a response in the wrong position in the file. You would think they would have double checked that. I guess everyone is busy. Let's hope this gets us past this problem.