Coding by Email

We finally got some new developers on our team. Unfortunately they do not have the computers they need to do any work. So now they are doing a lot of reading. Initially we thought their computers would be in quickly. Now it looks like that is not going to happen. The new plan is for these new developers to code by email.

Here is how this is supposed to work. An existing developer with a computer will email them the code to a non-development computer they have. Then coding changes will be done "in the blind". They then email the code changes back to developers who do have access to the correct computers. The theory is that this will allow them to do development. In reality, this is most likely a big fail.

There might be some good to come out of this. The new developer I am working with is longing to look at some real code on our project. This will enable that ability. However it seems to be a waste of time to have a newbie do some coding where they cannot even do a compile or run the application.

The optimist in me says that this is an interesting problem for me to do some coding in. I can perhaps code up a program that monitors for emails from the new guys, takes the code they send, tries to compile it, then returns the build results to them by email. If I can automate all that, I will be king. We can think of this as a sort of email virtual machine.

UNIX Developer

I am responsible for one of the subsystems on our project. This is just one of my side duties. Another team was overburdened a year or two ago. I was asked to step in and give them a hand. Turns out I inherited a subsystem for life.

The big boss said I could hand this duty off to another developer. I took that at face value. There are some changes that need to be made to this subsystem next year. Recently I noticed that some tasks for this subsystem were overdue in the schedule. That sounded like a perfect time to hand the whole thing off to the other developer.

Oooops. That other developer is out on vacation for a month or so. Looks like I am stuck with some extra work again. This is my own fault. As soon as the big boss mentioned that it could be offloaded, I should have jumped at the opportunity to pass it on.

Here is how I know I am not right for this project. It runs mostly on UNIX. Today I did not know how to copy a directory and its contents using the UNIX command prompt. Sure I was able to google the answer. But a developer for this specific project should already know how to do this.

The Power of Debug

A developer on my team got assigned a problem that was supposed to be fixed a long time ago. This developer could not determine the cause of the problem. He told our managers that his system was corrupt. He could not run Visual Studio in debug mode. Thus he could not identify the code that was causing the problem.

This announcement caused all kinds of excitement. Our team lead told the developer to report to our offices (he works in a remote location). He showed up and could not find the rest of our team. So he found an office and started working. Luckily another guy in a remote location informed me the developer had arrived. I grabbed him and we met with our team lead.

Team leader was a bit frazzled. The management team must have beat him up a bit. He kept grilling me and the developer about when this bug could be fixed. I asked him why he was talking to me about it. He said that I was now going to be responsible for helping the developer get the bug fixed.

Luckily I had did the initial analysis on the issue. I knew exactly how long it would take. The team lead kept trying to dissect the analysis to figure out how we could ship it out quicker. I stuck to my guns. That there were two people involved did not cut the estimate in half. One guy could not debug the app. Luckily when we got to my desk, built a debug version of the application, it was a short while before we found exactly where the problem was occurring.

You need to be able to run the application in debug mode. There is no substitute for this. If you cannot debug the main applicaiton, you must treat this as an emergency and get it fixed. Otherwise you will be of little use to a maintenance team. Even the managers can see that.

Design Test

This year I got assigned one of the main changes to our system. The hard part was nailing down the exact requirements for what I needed to change. Once that was done, I went to town documenting a design for the changes.

The big boss told me I would do the design. But a new developer would code the changes. With that in mind, I made sure I explained a lot of details in the design.

Today I reviewed the requirements with a new developer. Then I provided him with my design document. The test was to see whether the design gave him enough info to allow him to write the code. He only had one or two questions after going over the design.

The next step is to design some of the changes the customer wanted but were not approved on the first time around. I know they are going to want everything they asked for. We just got a break in that all the changes are not due immediately. The rest of the changes will be in a staggered roll out.

New Hires

Our team is finally getting some new members added. We have been struggling with a limited staff for what seems like a whole year. Now we got some new blood. The challenge is to get them up to speed as soon as possible.

In my opinion, we should throw some bugs their way. You learn a lot about our system when you fix the bugs. That's how I learned most of my domain knowledge. You really don't learn as much when you add a new feature here or there. The only problem with this is that we don't have laptops for the new folk to use yet. So fixing bugs is out of the question.

The current plan is for the new peeps to pair program with experienced developers. This has worked well in the past. One of our bright stars spent the first few weeks shadowing me on some new development. He says he learned more during those few weeks than he has his entire time being here.

I got one guy shawoing me at the moment. So far I have gone through development of one of my scripts with him. I also reviewed some requirement changes with him so we could help another developer on the team. The only difficult part of this arrangement is that my new guy lives far away. He has a massive commute to get to my office. We worked out a deal where he spends two days a week at my office. Let's hope he learn a lot.

Case of the Missing Data

Our customer has been reporting that some of their screens are coming up empty. However they perform a SQL query and find that there is data there. This was quite a mystery that we could not recreate in development. I took a look at the code involved. Somebody suggested that I inspect the databsae table that gets populated by a stored proedure and used by the application.

I found the database table name. But I needed more info. Which schema is this table contained in? I found out it was in the main schema that holds most of our tables. Then I found some strange code that seemed to delete all records out of the table every time somebody logged in. What kind of race condition did they set up here? Before jumping to conclusions, I decided to test out the use of the table with my app.

When I ran the app, I saw data in the application. However I could not find any data in the table when I ran a query. That was strange. This was my own private schema. Nobody else would be working in it. Then another developer thought that the app might be deleting the data. That was a possibility. I decided to remove the app from the picture completely.

I just used some SQL to insert data in the table. I could immediately see the data. However when I tried to query it from another tool (connected in a different session), the data was not there. Aha. I determined the behavior of the table. It turns out it was an Oracle global temporary table. The data was private per session, and removed after session end.

Sometimes you got to test things out for yourself to gain understanding. This was one of those cases. I was not up to speed on how Oracle global temporary tables work. But I knew how to run specific tests to determine what was going on.