Last Minute Changes

Today there was a meeting scheduled with the customer to review some last minute requirement changes. I went to lunch early so I would not miss the meeting. I dial in to the conference, but all I get is elevator music. After a while, the requirements team calls me up. I find out that I dialed the wrong number. This was a bad omen.

We get into the meeting. The requirements team drives the discussion. But they always go to me for all customer questions. This time around I had them document exactly what the code does. The danger is that this opens up all kinds of discussion. Now is not the time to discuss. We are at the end of testing. However it is better to get the bad news now than later after the code is running in production.

I get banged up a bit. There are some surprise requirements. I take it in stride. Right after the meeting I am banging out code. Luckily I have a huge unit test code library that helps me test out the changes. But guess what? I found a bug in my unit test data generation routine that is affecting the latest changes. I debug that and then test out all the new stuff. Oh boy this is so last minute. Luckily I am going on vacation next week. People on the team are scrambling to figure out who will be backing me up next week. Rant off.

LOL

I had a ton of messages on my phone when I got in this morning. Nice. One of them was from my team lead. He usually does not call me. So I got in tough with him right away.

A project manager had asked him to get me to check up on a customer problem in the production environment. Apparently he thought this would take me all of 10 minutes. It actually took longer than 10 minutes for me to even understand what the heck they were asking.

Here is what I gathered. The customer testing group had some concerns over some processing. Our manager wanted me to mine the production data, figure out from the data whether the customer concerns were valid, and provide the hard evidence either way.

All I can say is LOL. If I were given a few days, I could knock out this work. But 10 minutes? Please. Each of the many queries I need to run against our huge production data set might take 10 minutes. Right now I don't even know how to compose the queries without doing analysis up front. My team lead is a true diplomat. He said that he would respond by saying that my hands are full, and that I would try to help if I got any free time.

Muhahaha. You got to love my team lead. He is a politician in the making. I actually work directly for a different manager. He directed my to spend my time working on some new customer requirements that need to go out ASAP. I was told that I can direct all my time on that task. I am going to follow my direct manager's orders for now. Still laughing at the 10 minute estimate though.

Small Changes Take Long Time

Some testers discovered some differences between our written requirements and they way our software was working. We decided to change the requirements to match the software. This really was a documentation problem. You would think this would be the end of the issue. No chance.

The customer inspected the requirements. They realized some other things were missing as well. Those other things were not in the software. Essentially the customer wanted some more last minute changes. They said this was important. Oh oh.

Now of course these changes were to be done by me. I was asked how long the changes would take. I conservatively estimated a few days minimum. My boss translated that into a 32 to 40 hour job. Why does such a small change take so long? There are many reasons. We got to make sure we get the requirements right. That job should go to an analyst. However you know a developer needs to be involved.

Then you need to code the change. That does not take much time at all. Next you need to do your testing. It is difficult to set up just the right set of unit test data. You also need to document all your tests. Guess what else needs to be documented? Changes to the design. This goes in the design document. Then we need to roll out the change to all the environments that need it. There is internal test, customer test, then production. Now 40 hours does not sound all that long.