“How does the utilization report arrive at its numbers?”

It seemed like a simple, straightforward and innocuous question at the time. Unfortunately, it opened an institution-sized metallic food storage container of blind, soil-ingesting invertebrates.

You see, the person who’d commissioned the development of the utilization report didn’t really understand what he was building. He had vague amorphous ideas about what he wanted – perhaps he’d seen a report at some other company that was used to determine how well the employees were being utilized and decided it was a good idea. Based on second-hand knowledge and investigation into the reports themselves, here’s how I picture the utilization report’s progression in my head:

Project Requester: “I want a report that tells me if there’s enough work for my employees.” –note: He’s saying “show number of hours worked divided by number of hours that could have been worked”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It needs to take holidays into account.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It needs to take PTO into account.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It  should use the number of hours the employee has been scheduled to work instead of the hours actually worked.”
Programmer: “What?”
Project Requester: “It has to.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. If an employee had a job that ran late the night before, the Scheduling department schedules an employee for a block of time the next day in order to keep him from having to work. The report has to take that into account when it happens.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It needs to show that an employee worked the whole weekend if he was scheduled for a Saturday.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It needs to assume every employee spent two hours to get to the job site and two hours to get home.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong.”
Programmer: “How is it wrong?”
Project Requester: “The numbers can’t possibly be that low. The report is wrong.” –note: It showed an average of 64% utilization (i.e. employees jacked off 36% of the time for which they were paid). It was later found that actual utilization was 52% if they were afforded every possible benefit of the doubt.

The utilization report was used to determine year-end monetary bonuses for managers. However, every time the utilization numbers were too low to allow the maximum bonus, the managers would say “The report’s always been inaccurate. The numbers are really much higher.” And the bonus would be awarded.

Given the tendency of Plus users to do the most illogical things possible while refusing to read or apply any kind of instructions given and then blame the software for behaving “unexpectedly”, it seemed only fitting to provide them with the one thing they couldn’t screw up: the Do Not Click button.

A lot of thought went into the Do Not Click button. Its placement was particularly important – it had to be accessible yet unobtrusive enough to go unnoticed for a while. The button itself had to be recognizable as capable of performing an action, yet simple enough to be overlooked by a casual glance. It had to display enough of a warning to be clear that clicking was ill-advised, yet low-key enough to beckon seductively. The final product is thus:

Fetching, no? It was placed at the very bottom of the About dialog, which I doubt anyone ever accesses unless by accident. If any one of the 150 users happens upon it, however, he’s all but guaranteed to email the other 149 to tell them about it. And that’s when the fun starts.

“What happens when the Do Not Click button is clicked?” one might ask curiously. Let me give you the most likely scenario:

User: “What’s this thing that looks like a stop sign with a white X in it? That looks weird. Wait, there are some hieroglyphs beside it…they say ‘d’…no, ‘D’…I’ve got it! It says ‘Do’! Phew, that was hard work. I’d better take a break so as not to strain myself.”

<- four hours later ->

User: “Why is there a window that says ‘About’ open? This stupid software, always doing things I don’t tell it to! I’m going to create a helpdesk ticket for IT to fix it! No, I should compose a poison-filled email about how crappy Plus is and how it’s always broken and send it to all of the other field technicians so they can join me in my uninformed griping!”

<- two hours later ->

User: “All that typing made me hungry. I’m going to go to the expensive steakhouse down the road and charge a hefty three-course to my company credit card and then take a nap.”

<- the next day ->

User: “Hmm, what’s this window that says ‘About’? There’s a button that has a stop sign with a white X in it. It doesn’t say what it does…<click> Nothing happened. <click> <click> <CLICK> Stupid Plus! How can I be expected to perform any work if this trashy program won’t do anything? Those idiots in IT are just trying to keep me from doing my job!”

Sadly, this is probably a realistic depiction of events. However, the Do Not Click button does do something – it records the number of times it’s been clicked. Yes, that’s right – there’s a persisted click count. When the user submits work (which is supposed to happen once every few days), the cumulative click count is stored to a server-side database along with the user’s username. There it waits until an intranet-accessible web page is requested, wherein it’s included in a report showing the users clicking the Do Not Click button the most.

And here’s the best part: Any “bug” report about the Do Not Click button being broken can be closed with “The button works as intended. Do not click the Do Not Click button.” When the question of why the button exists comes up, the answer is “The button is there to keep an issue from occurring. When the button is clicked, the issue occurs. If the button is not clicked, the issue does not occur. This is why it says ‘Do Not Click’ on the button.”

/**
 * Added 10/7/2009 by specific request of sjohnson. Of course there's no HD
 * ticket or other documentation for the request because everyone knows
 * normal rules don't apply to the field staff.
 */

Code comment written today:

/**
 * Removed 11/5/2009 by specific request of sjohnson. Of course there's no HD ticket
 * or other documentation for the request because everyone knows normal rules don't apply
 * to the field staff. sjohnson swears this is a showstopper and must be removed because
 * now that he actually has to work in Plus on a daily basis he understands how
 * ridiculously foolish it is to clear out the time entry fields after every entry is
 * added to the table.
 */

Mere days before a version of Plus was to be released, the manager in question demanded that the functionality be changed as it was “not the way the staff work”. He was made aware of the reason the product functioned the way it did and warned of the problems that would occur should his demand be met, but these logical beseechings fell upon deaf ears. He was given an opportunity (two full weeks) to test this change and he signed off on the final product. Almost exactly a month later, the manager had to take on the role of a field technician. As part of that, he had to use Plus, and blamed me for “making changes without [his] knowledge”.

This manager demanded that this and a second change be immediately coded and pushed into production as an “emergency” release…without any testing. He was warned of the expected problems of the second change and how testing helps ensure quality, but again he exhibited Deaf Man’s Vendetta. We’ll see how that turns out.

Update: A week later (11/13/2009) the same manager went into another panic and demanded the functionality be reverted again, emailing “can you please verify and correct this issue immediately? This is the same issue we had in October!”

As relayed in previous posts in this series, the Plus application was meant to facilitate the transmission of data from field technicians to the home office. However, at some point it was decided that Plus should also be responsible for transmitting and displaying data from the home office to the field technicians. This information ended up being things like equipment-specific metadata, customer contact numbers, location of each piece of equipment, a directory of everyone employed at the company that developed Plus (no, I’m not kidding), and schedule data. All of this came from a poorly-standardized, non-normalized database used by the company’s CRM application, Nexterna Clearview, which uses a batch-and-post system.

The schedule data was an important piece because it gave the field technicians a way to see scheduled work without having to use any brainpower. After adding this information to the Plus application the powers that be decided Plus should use it to automatically determine and display the appropriate data forms for the technician to fill out for each site visit. It was further decided that the forms themselves should dynamically change based on the equipment information from the CRM application.

Eventually this was all made ready and deployed to the field technicians. As usual, there were exclamations of “Wow, this is great!” and “This will make us so much more efficient!” at first. But soon the users started reporting problems. They’d enter data into a form and it would disappear the next time they downloaded schedule updates from the home office. It turned out Jim built Plus and the Plus server to use auto-generated database record IDs as unique identifiers for schedule data. When a field technician entered form data, it was tied to the schedule’s database record ID. When the form data was sent to the home office, the Plus server displayed it to home office users by establishing a link between the schedule’s database record ID and the record ID in the returned data. In a normal world, this wouldn’t be a problem – using database keys guaranteed to be unique is good practice, right?

The issue came into play when one of the schedulers at the home office altered a schedule after a field technician had already used Plus to enter form data. The scheduler, called a ‘CSAM’, would change the schedule’s location, equipment, date, assigned technician, and even go so far as to delete the schedule altogether and create a new one in its stead. The next time the field technician used Plus, he saw a set of blank data entry forms assigned to the new schedule instead of all the data he’d already entered under the old schedule. In essence, data entered into Plus was “lost” due to the normal day-to-day operation of the CSAMs.

Later I found that there had been many a heated argument betwixt Jim and benson about the use of auto-generated database record IDs as data keys. “That’s not how the users work!” benson would exclaim. “It’s the right way to do things!” Jim would shoot back. The end result was always the same – Jim would simply continue the way he wanted.

For quite some time people just blamed Plus for everything. “This stupid tool loses my data!” they’d gripe. “It eats my work!” Eventually I was able to show that a very small change to the existing CSAM scheduling process could avoid the majority of these situations, and the complaints changed to…well, they didn’t change at all. Everyone still made Plus the scapegoat, and the CSAM group refused to believe they could possibly have anything to do with the issues. Their leader wasn’t willing to even admit it was a possibility.

Finally I rewrote enormous chunks of the Plus application to use less volatile keys that mapped more directly to the way the users worked (vindication for you, benson). Of course, at the same time the CSAM group finally conceded to make that one tiny change (it took the head of the company to get even that), and they’re taking credit for reducing the number of issues with Plus data. Oh well, only 11 more days…