Battle and War

Today my manager pitched a solution to my scheduling problem. He said we could add the new task after my current task is complete. There were a few loose ends that I needed clarified.

My team lead wanted me to work on a different task after my current task ends. We negotiated that I could get help on this second task, so that I could still work the new task.

Things will still be tight. But I think I can manage. I asked my team lead for a little more leniency. However he said we all need to pitch in more time. The downer is that this needs to continue for a few more months.

I am a salaried guy. There is no extra pay when I work extra hours. Occasional overtime is acceptable. But it is not right if this extends forever. There must be other opportunities where you don't have to kill yourself at work. I won this one battle, at a high cost. The war on work is far from over though.


Me and the guys scheduled a meeting with another contracting team. We had to lay down the common design for the new stuff both our teams shall be implementing. We decided to meet at our customer's big facility. The customer has a lot of rooms. But there is minimal parking. I was worried that I would not get there in time for a parking place. Luckily there must be a lot of people on summer vacation. I got a parking spot even though it was late.

I called up a coworker when I got to the place. Somebody needs to sign us in. You don't get badges unless the customer facility is your regular workplace. I got lucky, and the guy I called was just coming in. All of us got to the meeting room in time, except for the new guy. I gave him a few minutes. When he did not show, I started the meeting without him. The show must go on. It was a productive meeting. We discussed a lot of scenarios that I had not thought about previously. We planned a tentative action on how to handle all those scenarios. Then we negotiated the details of the database changes to accommodate the new features.

Later I found out that the new guy got stuck in traffic. They closed down the road he tried to use to drive in. As a result, he was very late. By the time he got to the customer site, there was nobody available to sign him in. He proceeded to return to our company's office. Not a good sign. We got to get this new guy some more contacts in the customer facility.

Training Scam

An old friend of mine had been doing contract programming work this past year. However he lost his job as part of some downsizing. He is collecting unemployment. There was some sort of opportunity for the unemployment office to fund some retraining. My buddy wanted to learn web programming. That sounded like a good plan.

A local company won the bid to train my buddy. They had a great plan on paper to team my friend Dreamweaver and deep Flash animation. My buddy said the unemployment office spend a few thousand on this training. There was just one problem. This training was a scam. My friend got some second rate training material. But there was nobody to instruct him who knew anything. Perhaps this firm was preying on people who did not know HTML from their ABC's.

My buddy did not have a personal beef with the owner of the "training firm". He just wanted his training dollars to go toward some real training. He tried to work with his unemployment office to blow the whistle on this scam. However they were busy covering their own behinds. Nice. If it were not so evil, I would advise my buddy to join the scammers. He actually has got in good with some of the employees of the scamming organization. However that road leads nowhere good. I could only wish him the best at getting another development job. Maybe then he can get his new company to sponsor some real training. Until then, keep an eye out for training scammers. Go with firms that have been recommended by people you know.


A month ago, my team got called to headquarters to discuss lateness in the schedule. We were behind. And upper management did not know why. I broke it down to them. We have the ability to accurately predict how long it takes to do stuff. You need to schedule that amount of time for developers to do the work. If you do not, guess what? You become behind schedule.

At this meeting we showed how our estimate put the current task way behind schedule. The big bosses said that was not acceptable. My team leader came up with some tricks to slice the work so it looked like we were not that far behind. But this was just smoke and mirrors. We were then signed up to meet an ambitious schedule. I took up the challenge. After all, I am not a slacker.

This week a lower level manager told me I needed to take on a lot of new stuff. I told him that would put us behind schedule. He said that was fine. I told him we needed the blessing of upper management. It took a while to schedule a conference call from the suits at headquarters. However they wanted to know how we were getting into this situation. The top dog directed me to project the time needed to do the new stuff, determine the impact to the current schedule, and let him know who else could help us make the current schedule.

I did my due diligence. After a while I had a list of tasks with expected durations for the new work. Then I showed how this would have a direct impact on the current schedule, slipping it to the right. Finally I gave suggestions on how adding new people to the task would help pull the schedule in. Do you know what the response from the top manager was? He asked what my plan was to meet the current schedule without adding resources. That was precious. He mentioned that I could extend work days and work weekends to make it so. I guess the reason why he gets paid the big bucks. Go figure. More on this crazy situation later.

New Changes

Today we met with our customer and pitched the design for the new changes. This is an opportunity to help them see how the system will look with new functionality built in. It also let's them validate that we got the ideas right.

In the middle of our presentation, our customer asked if some new fields would be shown on all the screens. Previously I had not thought about it. But it made sense. It would not take that much effort to add the new fields everywhere in the displays. That change got added.

Later in the pitch, a developer on our team asked whether we were going to implement a lot of business rules to prevent some new operations from taking place. I said we were not. Another tester asked if we would put confirmation dialogs in. Again I said no.

It is a fine line to decide whether to add extra features to the software. You do not want to say yes to everything. That will add risk to us not delivering on time. I do want to add those things we should have added, but did not. It is definitely an addition if those items are things the customer needs and it will not take long to implement. I will fight against additions that add risk to the schedule. And I don't think we should do anything just for the sake of it. There should be a customer benefit from anything we spend time on developing. That's my two cents.

Non Trademark Battle

Phil Bewig has a blog called Programming Praxis. To tell the truth, I had not heard of it until today. He had previously tried to work with Alex Papadimoulis of The Daily WTF. However the deal fell through. Phil's beef was that The Daily WTF continued to use his blog name after negotiations failed. Phil ended up sending a cease and desist letter to Alex.

At first I thought this was a big site (The Daily WTF) trying to muscle out the little guy which is Phil. However this is a little more tricky on the legal side. Phil does not have a trademark on his blog name. So legally he does not seem to have much leverage. Regardless it is no fun when a big company takes your name and uses it successfully.

I deliberated on whom to side with in this case. The deciding factor was when Alex conceded and decided to stop using the blog name in The Daily WTF. Good move Alex. And for that good move, whatever the motivation, I will give Alex some link love. Phil just gets a mention in passing. I think he might have just had his 15 minutes of fame.

Never Again

Last week we had a disaster with our production system. About a month prior, we had switched over from FTP to a more secure mechanism to transfer files. The secure mechanism was a proprietary one from our customer. There was one problem with this plan. We did not have an environment to test this. The production environment became our test bed.

The first transfer worked fine. Everybody thought the transition worked out ok. Then we all got busy with other work. After a few weeks, the customer realized that the transfers did not work after the first day. Doh. The end result was that the customer lost a lot of money. I am afraid heads may have to roll for this one.

The top brass from the customer organization want an investigation as to how this happened in the first place. They want to be sure that it never happens again. Our company is stating that we will need a test environment to simulate production, otherwise we cannot guarantee anything. Now might not be the time to be making demands. Otherwise we may be losing this big customer. I will let you know how this pans out.

Busy at Work

Today I got in and the two developers I was working with were engaged in design. That was good. Gave me some time to check my email and voice mail. Oh oh. Some tester said he was having problems with my code. So I called him up.

The tester read some requirements and came up with a test plan. That is a good start. However he did not understand how the system worked. Not good at all. He got confused and decided the software must not be working. I spent a good amount of time setting him straight. That prevented some bugs.

Later I had a slew of meetings. One such meeting was important. Had to meet with a developer from another company to talk about how our software would interface. The tester from the morning the got confused again. I did not have the time to hold his hand, so I had to blow him off. Now I have a bunch of defects I have to answer.

Then late in the afternoon a new developer cornered me. He knew I was going on vacation soon. The guy was not up to the task of doing some design. He had a lot of questions. I told him I could only give him a couple pointers. He wanted much more. I told him to dig into the code and reverse engineer the source to figure out what was going on. Even that eluded him. He asked what that meant. I walked him through one example. Then I think he got it. I tried to escape from this crazy work day, but people were running after me telling me not to leave. Insanity.

Developer or User

The guy who leads my team called me up today. He read a requirements document and could not figure out what the heck our software was supposed to do. Luckily I am a domain expert on our system. I kept answering his questions, correcting his model of the work, until he finally got it.

Later my team lead called me up saying he found a way to shortcut the developer time needed to do the new functionality. We would just implement a process where once a year a developer writes a script to implement the specifics for the users for the given year. I had flashbacks of the last time we did this. The result was years of agony.

So I walked my team lead through the scenario. I asked him who was going to do the actual script writing. He told me a DBA would do it. Then I asked him how the DBA would figure out the specifics of the data to put in the script. He did not know. I told him the answer. They would come to us. We don't want to have the job of tracking down the information necessary for each year. We want to provide the capability for the end user to enter the data. It is their job to figure out the specifics that relate to their business.

I cautioned my team lead against creating a solution that requires developer work every year. It is no big deal to knock out a script in 30 minutes. The problem is that it may take weeks and weeks to track down the data needed to put in that script. We are always too busy in development at the end of the year. I even volunteered to work overtime to design and code the automated solution which gives the user a GUI to do this. So you know I am serious about the right way to meet this need.