Brian Kohrs’ Blog

At work they were selling a bunch of the old PC’s, and since my dad was wanting a laptop, I picked one up for him. One of reasons that they are selling the machines is that they have no networking capability (another long story). My dad picked up a Linksys PCMCIA card, and asked me to install it so he could connect to the network. This should be easy to do, right?

So, I stick in the cd to install the drivers, and get a prompt that you need IE 5.5 or greater to install their software. So I go up to the Microsoft site on another computer that has networking ability and download the IE 6 setup program. After copying it to the laptop, I fire up the install, and it says that it will need to download 13.9MB of files in order to install. That is not going to work with no internet access.

Being a technically savvy individual, I take a peek at the cd. There is a folder with the drivers in it, so I stick the network card in and install the driver. Now Windows detects the card, but there is way to select a network to connect to. Looking at the cd, there is also a utility folder with a setup.exe in it. Launch the setup program and now had the Linksys software installed. I fire up the software, and it says that it is searching for a network, but it never finds anything. This is not going very well so far.

Since my manual installation fails, I uninstall everything and start looking at trying to get an installation of IE 6 that does not require any downloading on the install computer. After a bit of googling I found this site. It seems that if you pass super special parameters to the installation, it will allow you to download all of the files that are needed. After copying all of these to the laptop, I install IE 6 successfully. I then run the official Linksys setup program, and everything works just fine.

We have had a performance issue floating around at work where one operation was taking about 15-25 times longer than it did on previous versions. Obviously an issue that needed to be addressed. A couple of months ago, when we first identified the slowdown, we wrote a story card to find out how to speed it up.

Pair #1 picked up the card, and identified a way to speed it up some, and implemented their idea. Well, it was a little faster, but it broke a bunch of tests. They go back in and make a couple more changes. Now only a few tests fail. Since we had already spent more time than we should have trying to fix the tests, we decide to back out the changes, and have another pair take a look at it.

Pair #2 makes similar changes, but this time they don’t break the tests. It speeds up the operation a bit, but it is still far slower than it should be. At this point we write up a card to see if there are any other ways that we can speed it up.

Pair #3 finds that the we are not accessing the database in the most efficient way, and implement changes to reduce the inefficiency. The operation is faster, but still not fast enough.

Then comes this week when we have Don Roberts in as a consultant. We figured that since this is why we bring in highly paid consultants, we should let him take a look at it. Sam and Don picked up the card and ran a profile to see where the slowdown was. Initially, looking at the profile generated no new ideas. Digging a little deeper, we found that it was updating around 1/3rd of the records in a table, much more than we would have expected. Bringing in our resident expert Kim, we find out that most of the values it was saving were values that we calculate anyway. So we change it to only save the values that we need to be able to calculate the others, and about 99% of the updates disappear. Now the operation is much closer, and in some cases faster than it was in previous versions.

This one issue is really a testament to the value of pair programming and the agile process. If we all programmed in our own little cubes, we probably would have eventually found the issue, but it would have taken so much more time.