You are viewing [info]codefox's journal

Previous Entry | Next Entry

You know it's time to fire your consultant

codefox
So I've been at Gold Standard for over a month now. Currently in my 6th week, actually. So far, I have no complaints. The work has actually been better than I had hoped for. I knew I was going to get a lot of the 'noone-wants-to-do-this' type assignments, of which I have plenty. These mostly deal with preparing our monthly and quarterly database updates. But not a big deal...the quarterly stuff takes a day or two to take care of and the monthly stuff just a few hours. We've been extremely light on tech support calls, which, as that's my actual job title, is a bit amusing since I rarely do any tech support.

What I do mostly is the project I've had for 3 or 4 weeks now working on the 4D database system that they use to track sales, shipping, and a variety of other things. The 4D database I've already described before so I won't bother again. The guy who had been working on it has been fielding some calls from us on a particular issue that popped up shortly before I took over the project. The issue was basically that in the new Tech Support module under development, the client gave the user a warning that the record was already opened. It was a very odd error because it told the use that they had it open on the current computer being used. Obviously something wasn't adding up.

My original suspicion was that it was a local problem and not a server problem. This was because the problem might be on one PC but if you went to another, you wouldn't see the problem there (right away). Our 'consultant' for lack of a better term, was adamantly against the idea it was the client (and therefore, a coding problem on his part) and insisted the problem just HAD to be in the actual database. It was corrupt! Despite the fact that repair utilities contradicted this opinion. But I figured I should listen to him. I mean, I've been working on 4D for since July 9th. He's been working on it for 10 years.

For over a week, I've been struggling to figure out what the problem was. My boss and another VP were both beginning to believe the problem was so deeply ingrained in the code (we're talking about a program that's pushing 10 years itself) that we'd never find it. We had a meeting about it yesterday where Mr. Consultant continued to toe the line of a database, rather than client problem. Finally we hung up on him and discussed it ourselves. The other VP knows the client itself like the back of her hand and showed us a directory that neither I nor my boss had known existed. And it contained exactly what I was looking for when I originally heard about the problem. A file on the local machine that was updated every time the program ran. Now I was onto something...I had a feeling I'd find the solution now.

And sure enough, after a few hours of working on it today, I found out that it was everything I originally though. The file on the local machine was a cache file that the client created. A search on Google revealed it was well documented that this file is easily corrupted and if that happenned, would cause erratic and nonreproducable errors. Which was exactly what we were experiencing. I was a bit annoyed now, because for someone who claimed to be the 4D Master...for him to have not mentioned this as a strong candidate for our problem was absurd. I knew the moment I read about the symptoms that I found where the problem was.

Sure enough, deleting the cache file temporarily solved the record locking problem. But it kept coming back. Now that I knew it was a local problem...it had to be the code. Despite his assurances over and over that there was no way his code was opening records incorrectly, I knew it had to be somewhere. And I also knew that the problem wasn't happenning every time. And it turned out that the programmer account that was used to debug it was one of the times that you could open the program and not corrupt the cache. Well as it turned out, the programmer account wasn't, in fact, using the entire program...it was skipping over sections that would only activate if you were say, Tech Support.

And 'lo and behold, what did I find, but the lines of code that were opening up records and then not closing them. Leaving them in memory to be corrupted since the most common and logical thing that the user is going to do is open up the exact same records again. The first time they're opened is to tell tech support how many trouble tickets they've been assigned. Obviously if you have a trouble ticket, you're going to go look at them. Soon as this happens, the data became corrupted. And this was precisely what Mr. Consultant (who we've probably paid for 3 or 4 hours worth of consulting on this problem for wrong information) claimed he didn't do, and was impossible even, in his program. Needless to say my boss seemed very happy when I told him the problem was no more. And I've made sure to let everyone know that the guy they've been paying for his help was entirely wrong on every count and it's been his shoddy code that I've been rewriting for the past 3 weeks.

I've eliminated at least 10 or 11 bugs and added several new features since I started on this. He's known about this one problem for almost two months and couldn't fix it. I'd say he's probably (hopefully) seen the last of our money.
  • Add to Memories

Profile

codefox
[info]codefox
Codefox

Latest Month

March 2011
S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728293031  
Powered by LiveJournal.com
Designed by Teresa Jones