Diagnosis? Easy. Fix? Murder

It's long, long ago at the manufacturer where this IT contractor pilot fish has been tasked with fixing a printer problem.

"Two users sharing a printer would both submit print requests at the same time, and the lines of text on their printouts were intermixed," says fish. "This was particularly annoying because these printouts were manufacturing instructions for highly customized products.

"I began by watching the users duplicate the problem. While doing this I learned that one of the users had recently been assigned to this particular job in what had formerly been a one-person office.

"Then I went back to my desk and began looking through the source code to see if there was any obvious reason for this peculiar behavior."

Sure enough, fish almost immediately discovers that the program has been written to print one line at a time to the printer instead of one document at a time. OK, he can fix that.

But when he tests the new version, the printer throws an error every time. Patiently trying variations, he determines that up to five lines at a time will print fine. More than that and it fails.

He keeps digging. Turns out that every printer is defined in the operating system as if it's a terminal, which accepts a much smaller block of text than a printer.

A few changes later, fish can print multi-page documents without errors or problems. Great, he thinks -- now who do I talk to so this can be put into production?

Answer: "The same person who wrote the programs I had just modified," fish says. "I went to talk to her and explained both the problem and the fix.

"During this conversation, it became apparent that she didn't really understand the tables that defined the printers. But that was OK -- once I showed her the fix, I was sure she could copy it. That's how she made the mistake in the first place: She copied the terminal definition to create the printer definition."

Fish tells the programmer that their manager has set a one-month deadline to test and install the fix in production.

After a few days, he checks back. Are the changes ready for testing? Her reply is noncommittal.

A couple more days, same question -- and same vague non-response.

After three weeks, fish reports to the manager that if the programmer is too busy with priority projects to make this change, they'll miss the deadline because there won't be any time for testing.

"Three more days went by," said fish. "Then the manager informed me that she was making the changes and we'd have to squeeze in the testing any way we could because the production deadline was non-negotiable.

"He also subtly informed me that I shouldn't have embarrassed the original programmer by finding errors in her earlier work."

Sharky won't embarrass you -- in fact, I'll file the identifying marks off your true tale of IT life. So send it to me at sharky@computerworld.com. You'll score a sharp Shark shirt if I use it. Add your comments below, and read some great old tales in the Sharkives.

The Best of Shark Tank includes more than 70 tales of IT woe submitted by you, our readers, since 1999. Which all goes to prove, conclusively, that hapless users and idiotic bosses are indeed worldwide phenomena. Free registration is all that's needed to download The Best of Shark Tank (PDF).