When better isn't better

Pilot fish works at an IT services outfit that's trying to get a contract with a very large public transportation company.

"They wanted to offload some schedule simulation programs to free up their mainframes for other work," fish says. "But before they would sign the contract, they wanted us to run the software on our machines to see if they would get the valid results."

Fish and his cohorts port the Fortran code to the new machine and make a test run so the results can be compared with what they're supposed to be.

But before sending the results to the potential customer, fish and his team check everything against the expected output that the customer has sent to them.

Turns out that the new results are slightly different from the expected results -- but that's because the ported software generates results that are more precise than the old version.

And having demonstrated that they can run a better simulation of the real world than the customer's own machines can, fish's group is looking forward to a nice big contract to run the code.

The output goes to the transportation company. And the response comes back: These results are unacceptable.

The reason? "Your results show that it takes longer to actually complete the route, and the managers don't like to see that we're not as fast as before."

The fastest route to Sharky is through my in-box: sharky@computerworld.com. Send me your true tale of IT life, and you'll snag a snazzy Shark shirt if I use it. Add your comments below, and read some great old tales in the Sharkives.

Now you can post your own stories of IT ridiculousness at Shark Bait. Join today and vent your IT frustrations to people who've been there, done that.

Copyright © 2010 IDG Communications, Inc.

  
Shop Tech Products at Amazon