Deep Analysis

Yesterday my project manager told me to attend a meeting with another group. These people are planning to write the next generation of our system. I was concerned that I would be talking to the developers that are trying to code me out of a job.

Luckily I went to the meeting and found they are in the beginning phase of analysis. They wanted me to let them know where we get all the data from our system. They also were very interested in how we store internal state of the applications in the database. I had to take an action item on those tasks.

I made sure I did a pretty good job analyzing our system. These people might be my new bosses in a few years. It was a challenging task. Shouldn't there be some database tool that tells you what database tables is a schema are actually being accessed? I don't know of a specific one. Do you?

Agile Success

A whole host of agile technologies have become mainstream over the past few years. These include refactoring, unit test, test driven development, and even Scrum. However pair programming is stuck in the mud.

One problem is that pair programming is expensive. On the surface, it takes twice as much to do pair programming. It is also not liked much by developers. It might be one of the agile methods that never pan out.

However it is the end results that matter. You want to know immediately when the build breaks. That might mean you have unit tests that automatically get applied. Or a build job checks for errors and emails the right people. We don't have that at our work. We used to. But the build scripts got rewritten, and are not as good any more.

Client Connections

You need to understand that every time you meet your client, it impacts the relationship. Clients want an emotional connection with you. You need to understand their expectations to be able to meet them.

The experience the client has must be positive and special. How do you ensure that? Show passion. Be committed. So how do you make sure your employees have passion and are committed? Put them in the right roles.

Be sure to put in that quality time with your clients. Otherwise another company will get a better relationship with your client. Then you lose clients.

Developer Coverage

The managers have a policy on taking vacations. You need to make sure you have somebody covering for you. A developer on our team was taking a massive one month vacation this past month. Then she needed an extra week to care for a sick family member. She was supposed to arrange coverage for her tasks.

She ended up letting our team lead figure out the work coverage. That was a bad move. Our team lead asked two members on our team get familiar with some code changes the vacationing developer was going to make. These members just got familiar with the code changes. In effect, they made sure they could check in code changes on the vacationing developer's behalf. This happened and the software was released to test.

Then the testers needed help figuring out how to do the testing. That was a problem. One ghost developer had checked the code changes in. However knowing what the fix was fixing was beyond comprehension. I got the players involved on a conference call to clear up who was supposed to do what. Apparently the job of the two developers was to gain a better understanding of the actual problem that was being fixed. That makes sense. But you need to be explicit about this if you are giving out directions. That did not happen. This all could have been avoided if the original developer going on vacation had arranged and trained up someone who could provide coverage. That means somebody can do everything the vacationing developer would do if they were in the office. Sometimes the manager policies are actually there for a good reason.

Improving Requirements

Previously I had pondered about techniques to improve requirements analysis. That's why I read a recent Doctor Dobb's Report article on this very topic. To start you need analysts that have skill. This is a tall order to fill. Then you need to make sure you have the right tools. Well we have IBM Rational ReqPro. So we should be good.

The analysts need to identify the business objectives. I know this is sorely lacking for many of our requirements. Often time nobody on the team understands why we are implementing the changes. We also must determine who can speak for the customer. This gets difficult when we have multiple customers that we work for. There is a sponsor, some executives, system acceptance, and different business divisions.

Use cases are a good tool. But they do not solve everything. The analysts need to get down into the functional requirements. Often times our analysts struggle with the business requirements. In that scenarios, there is no chance to do functional requirements well if you are stuck at the business level. You should also do some testing of the requirements themselves to see if there are any holes.

I think I should pass this article to our requirements analysis team. The problem might be the normal one. They are too busy to do anything other than write stuff down that the customer is saying.

Power of Documentation

We have a requirements analysis team. I think they are supposed to work with the customer to figure out what they want. That is a daunting task. It turns out that this team frequently comes to development to ask us what the requirements are. There is something very backwards about this arrangement.

These requirements are then verified with the customer. They are also used by our internal testers, as well as the customer's acceptance test team. It is crucial that these requirements are clear and correct. Lack of clarity means someone is going to get confused. This confusion is a source of trouble. Customers will think they are getting something else. Testers will think the implementation is not correct.

One thing is for sure. It is best to have the requirements correctly documented during the requirements analysis phase. Unfortunately this is not an easy task. And therefore it is not always the way work gets done. We must still strive for this optimal setup for design and development.

Work Assignments

Today was the last day at work before my week of training. I actually completed my tasks in the morning. However I did not want to get bogged down with any new jobs prior to my training. So I stayed low for the afternoon. Luckily nothing popped up.

I have found that this is becoming a pattern with developers on my team. There is never a reward of leaving early if you work hard and get your tasks done. Your reward will be more work. More often than not, that new work will be something that keeps you late into the night.

There is no specific reward for getting done early and taking on new tasks. This is a bad setup. Developers are smart and will make sure to minimize such "rewards" for hard work. I don't have the answer on how to fix this problem. Because I am one of those who does not volunteer for extra tasks that much. Why do it? It just does not make sense. Just saying.

Screaming to Refactor

I am in the middle of coding some change for our next incremental release of the software. After implementing some changes in a stored procedure, I ran my tests. Something was still not right. I traced it down to a trigger calling a stored procedure. It was undoing my changes on the fly. I needed to make another change.

When I got into the other stored procedure, I was lost. The procedure was 850+ lines of code. There were nested IFs that were six, seven, and even eight levels deep. I was around when this procedure was changed over the years. And I still was getting confused over the thing. I decided to print out the code, and line up the IF and ELSEs.

My goal was to refactor this massive procedure. The plan was to break down this monster proc into many subroutines. In the end, the main procedure got down to 150 lines of code. It was much easier to follow. Of course all the lines of code went to small subroutines. I needed to do a bit of regression testing to make sure I did not break anything. With a change of this magnitude, there are going to be some bugs introduced. My unit tests helped flush them out. I am leaving this procedure is much better shape. I am proud.