Log in

No account? Create an account

Previous Entry | Next Entry

Happiness, Day 23

For the past few weeks I've been working on one particular segment of code. There are restrictions on how it can run and how it can be written. It runs in an environment where the data is frequently bad and deals with two sets of database tables that supposedly track the same events in different ways. Part of its job is to point out discrepancies between the two sets of data.

Over the past few weeks, new things have been added to it. The task document for it is full of different entries in different fonts and colors, pasted from emails, IMs, web pages, and Word documents. We (my supervisor and I) made the mistake of getting the requirements from the subject matter expert, but not showing him the work in progress, so it wasn't until it went to QA that we discovered we'd done several things quite wrong. (To be fair, the subject matter expert didn't think of them as things that could go wrong until he saw the results of the test data.)

The past week has been an attempt to make up for that in the little time left before we are due to actually release the code. The code has been back and forth between me, the subject matter expert, my supervisor, and QA, several times. This morning we had a meeting on what we could cut out of it. This afternoon we discovered that the new guy doing the code builds had made a mistake and promoted the wrong version to test. The dba took it over for a while (because of performance concerns) and scrambled some of the data.

Late this afternoon, a new critical support ticket came in, saying the new version was miscalculating information. We all groaned, in part because we hadn't touched the part that was supposedly malfunctioning. We'd thought that part was fine!

So tonight I'm happy because I dug into the database and discovered that the person who reported the ticket made an error. The program was reporting the data correctly, it was just unexpected data. So this was an example of NP-Complete's Second Law of Debugging: before digging into code and looking for programming errors, always check that you are not accurately reporting bad data.

Vindication: it feels good.


Mar. 20th, 2009 11:50 pm (UTC)
We have two unofficial rules in our support environment. Before doing anything, rule out user error and bad data. As in, your report's wrong? That's nice. Show us why.