There are times we programmers get so lost in code that we fail to notice the most glaringly obvious mistakes. This one kept me up for months.
Not a good start
I looked over the agenda for my Monday morning meeting with Manager X and it was still there – the numbers on the ‘Make All My Problems Disappear Report’ didn’t match with ‘The Other Report To Solve All My Problems’. They hadn’t matched for a few months, ever since The Conversion. Now, I would have to walk back into the meeting room and face the firing squad.
This particular problem had been gestating for some time. Over the course of several years, MS Access databases had begun sprouting on analyst’s desktops all over my department – a 1,500-strong global team. As you’ll know, it’s impossible to develop fully scalable, web-based reporting solutions in the same amount of time that a tech-savvy operations analyst can whip out an Access form and a few queries. We were the Empire and they were the Rebels.
Mission: convert reports
In an attempt to corral these feral databases the Emperor himself announced that all such nonsense was to stop immediately. All new reporting would go through MIS. All reports from non-sanctioned databases would NOT be accepted and their data would be subjected to grueling inquisitions. We’d won! The Empire was on the rise and we left work with our chests pumped; management had finally seen it our way. We were getting the backing we needed to implement our Comprehensive Reporting System. (Not the official name, but the real one wasn’t much better.)
And that’s when the problems arose. We began gathering requirements and started digging into the databases. We were assured they weren’t large but were stunned to find they were massive by Access standards. These were tracking databases with millions of rows, hundreds of data fields, 40 to 100 queries, multiple forms and a web of tangled code that stretched Access to its limits. They were abominations created by smart people with little or no training.
We were in a quandary. We had been given a project with deadlines and a mandate – bring the databases into the fold. A decision needed to be made and, with considerable hesitation, we decided to convert everything as it was. No changes, no code review, just get them into SQL Server and deal with the consequences later. Consequences like exhaustion from trying to explain mismatched reports. The meeting was a short one.
“Good Morning Manager X!”
“The numbers don’t match.”
“But here’s what I’m going to do Manager X. I’m going to spend the next week tearing these reports apart. Even if I can’t fix them, and even if they don’t match up next week, we’ll know why.”
He looked at me and smiled. “Attaboy.”
The Secret IT Manager shows initiative
I diagramed all the reports for his department, tracing them back through the many SSIS packages, views, stored procedures, temporary tables, back to the original staging tables and found where the previous developer had left all the dead bodies. The two reports were barely related to each other. They were distant cousins, at best sharing only a couple of reporting tables, but little else. Why does Manager X think these two reports should match?
I stormed into the meeting room with the determination of a Hollywood trial lawyer and threw down the piles of paper.
“They don’t match up. They have different criteria!” Manager X stared at me like I was a moron. Something seemed to dawn on him.
“What do you mean, exactly?”
I explained my research, telling him about the different reporting tables, associated reports with each, and criteria. His face twitched in understanding.
“You’ve named it wrong, that’s all. This isn’t the ‘Make All My Problems Disappear Report’. This is the ‘Make All My Problems Disappear NEXT WEEK Report’!”
Somewhere during the conversion process the name had been shortened and the other dropped as a duplicate. The two shared the same fields, but one was a forecast based on different models. In our haste to convert the reports we’d simply missed the easiest requirement – match the correct name to the right criteria.
Though it’s sometimes hard to understand how these mistakes are made, they do happen, and most often in a rush to implement a project in a timeline that is no longer feasible. We should have taken a step back, re-examined the scope, and presented our new findings to management. What we did instead caused grief to both ourselves and our customers. We take our lumps and move on.