Disorganization

Some test personnel in our customer organization wanted to meet with development to review some changes to our design document. My manager called me and asked when would be a good time for me. I told him this morning would be fine. Then I went and studied up the most recent design document. I found some errors. Regardless, I was ready to go through it.

Right before I went home from the day, some weird things happened at work. First I got forwarded a meeting invite to a different meeting at the same time. I ignored it since I had just talked to my manager about meeting the testers in the customer organization. Then I got a call from my team lead. He said he would take over the tester discussion. I was supposed to go to the other meeting.

This all seemed wrong. I had no clue as to the topic of the other meeting. It was supposed to be a review of our design for some other new functionality. My team lead told me to call some of the other invitees. I called up another senior guy. He said he was just as clueless as me about it. Then I got an email from my manager stating that he expected us to lead the design discussions on this new change.

Now I understand that I need to be able to present material in front of the customer. This is not a problem. I am actually quite good at it. However the reason that I am good is that I am usually part of the team that makes the hard design decisions. Then I make sure I learn the material deeply and prepare for any customer presentations. This setup was nothing like this,

I had to call up my manager and tell him I was not comfortable with this. In fact, I had a good mind to escalate this up to the senior management in my company. Luckily my manager heard me, and said he had a lot of ideas about the design and what we needed to discuss with the customer. At that point, I got him to be the guy to present his ideas to the customer.

Another senior guy later joked, asking me whether I was going to lead the discussions with the customer. I told him that it would be a short presentation if that was the case. I would introduce myself, bring up a question or two, and quickly adjourn the meeting. As it turns out, the meeting lasted a long time. We only stopped because there was another meeting which people had to attend after ours.

Schedule Surprise

This morning we had our weekly project meeting. The upper management in attendance was surprised that we were not making our schedule software release today. I said the project release date was two days from now. I myself found it unusual that they did not know we were slipping the schedule. The top manager in the room wanted to know why we were not meeting the schedule. I volunteered that I did not know that today’s delivery date was critical. However I added that we knew that date was not feasible a long time ago.

After the meeting I went to the latest release of the schedule. All of the tasks related to the one I was working on did not match the dates on the schedule. They were all way late. I guess my delivery slippage was the first time some of the upper management was alerted to the problems since my task was a very visible one. I immediately called my manager and said we had a problem. And I told him was going to escalate the schedule problems I saw up to the top manager on the project.

Finally this afternoon I got to speak with the high level manager. I told him that the dates in the schedule did not match actual dates for anything. I asked him whether he needed me to do anything other than inform my team lead or manager when things get off schedule. He said I should also try to work with them to plan a way to get back on schedule. He also said that I could escalate any issues up to high levels of management if I do not get satisfied with the reaction from my immediate supervisors.

I learned one important lesson from this exercise. I need to be more cognizant about the published delivery schedule, especially when I am the guy on the line for a delivery. So from now on I will study the schedule, and alert people when things are slipping. The best I can do is follow a process like this.

Hacking to Meet Deadlines

Our development team is understaffed and overworked. So what else is new? The requirements team needed some help. I drew the short straw. At this point, I am just going to slip the delivery date for some new stuff I was working on. You can’t keep typing me up in meetings if you want me to get some work done. But this post is about another anomaly here in development.

There was a trouble ticket that when users employ one of our applications to update a record, the UPDATED_BY field was not getting set. Another developer tried to research this problem. He asked me how he would know who is currently logged in doing the update. I told him we store this in our CWinApp MFC derived class. Sure enough there are strings in there for the user name and password.

Later I got a call back from this developer. He said he found the two data members in our class. However there was something screwed up with the values in those members. The user name variable was empty. And the password variable contained the user name. He was so busy that he just hacked in code that used the password variable to set who did the update.

At least he added a comment that this was a hack, and he confessed the wrongdoing to me. I could not fault the guy. We are so overwhelmed that there is no time in the budget to research and resolve side problems we find like this. The bad part is that bugs such as these escalate into further bad code. We got to put a stop to this nonsense at some time in the future. It just can’t be right now because we are in a state of emergency.

Junior Developers

Our development team has decreased in size recently. However the workload has increased. As you can imagine, this is not a good thing. I asked my manager what the most important tasks were. We decided I would work on a big change to the system. My manager asked if it would help if a junior developer assisted. The sad truth was that a junior developer would actually slow down the progress.

Here is the problem. The changes to be done are not well defined. This is due to some problems during the requirements gathering and analysis phase. As such, there needs to be some work done by development before we do the design and implementation. This type of work requires some experience and skills.

A junior developer would not be able to do the analysis required to figure out what to code. It would take more effort to do the analysis and pass that information off to a junior developer to understand and then code. By the time I have completed the analysis phase, the coding will be the easy part for me. All of the details will be in my head. Transferring that to paper or email so that somebody else can understand it takes more effort. It is even harder if that recipient is a junior member of the technical staff.

Part of the problem is that this is a vicious cycle. If the junior people do not get the experience, they will not graduate to more seasoned developers. But you can’t think much about the long term when you have immovable short term deliverables. We are trying to hire some new talent for our team. Luckily the last guy we interviewed was a developer with even more experience than me. I told the boss to hire this guy.

Need of Quick Fix

I just got back to work from a week long training course on Oracle PL/SQL programming. It was a good time getting away from the job. I checked in with my team to see how we were doing. There are a lot of open trouble tickets from the customer. The sheer volume of tickets is making us look bad. I am not losing much sleep over this. We are understaffed. Management accepted some new tasks which took time away from bug fixing. Now the project is suffering because of it.

My team lead asked me if I could find some trouble tickets which looked easy to fix and knock them out. That way we could ship them in the software release which is going out tomorrow. I decided to fix one such trouble ticket that way. The problem with the one I was fixing quick was that there way some hard coded data in a resource file.

Now the best way to solve this problem is to ensure the data is not hard coded in the resource file. We can use some build variables which contain the changing numbers, and get the resource strings to be built from them. The problem is that you do not knock out such a change in a couple minutes. This is my dilemma.

I could take the time to engineer the best solution. In the long run, it would help us to not encounter the same problem again in the future when the hard coded data gets stale. The customer hates old problems popping back up. However this would me I would be holding up the build. And there would be one extra trouble ticket open.

In the end, I decided to hack a fix for this problem by hard coding the new values that are valid for today. This does not sit well with me. In the software development world, this means the project is incurring technical debt. You let too much debt like this pile up, and you end up bankrupt. Nobody likes that. Perhaps I can make amends by doing the correct fix later this week. That will still take some effort since we still have a lot of other trouble tickets open which are crucial.

Interview Time

Our application development team has gotten very small over the past year. We used to be 7 or 8 members strong. Now we are down to 3. I have complained to upper management that I don't like having to deal with everything. That just means I work late every night and continue to work when I get home.

I thought convincing management of the need for more developers was the hard part. Now I realize that was just the beginning. It is difficult to find good developers. I suspect the really good ones use personal networking to find jobs. What's left are the mediocre developers looking for a job through traditional means.

Every developer we have interview has either been technically weak or a nut case. At this point I am willing to settle for somebody who knows C++ and has done some hands on Windows programming. Is that too much to ask for? I won't give away the secrets to our interview questions. But anybody who does real development should pass with flying colors. Our problem now is getting those types of candidates to our interviews in the first place.

The All Nighter

This week I have been in training to learn Oracle PL/SQL programming. My goal is to get Oracle certified. Yesterday was a long day in training, so I took a nap after getting an early dinner. When I woke up I needed a snack. I heard my home phone ring. Then I saw I had a voice message from two hours early. The customer had a high priority problem.

I dialed in to a call in number. A lot of managers from my company were in on the call. Apparently our software was not working on our client's test machines. It was also not working on anybody's virtual machine. I told everyone that it worked on my VM. I tried to log in remotely, but had some password problems.

To reset my password I needed to visit the customer's site. By then it was late in the night, or early in the morning. I waited until somebody from the customer site could let me in the next morning. I reset my password there, and found that the application works in my virtual machine. I provided all information about my virtual machine to another developer. Then I went off to my training for today. I hate it when high priority problems keep me up all night. But in this economy, you need to be happy to have a job.