Q: How to catch an Elephant in the Africa

MATHEMATICIANS: hunt elephants by going to Africa, throwing out everything that is not an elephant, and catching one of whatever is left.

EXPERIENCED MATHEMATICIANS: will attempt to prove the existence of at least one unique elephant before proceeding to step 1 as a subordinate exercise.

PROFESSORS OF MATHEMATICS: will prove the existence of at least one unique elephant and then leave the detection and capture of an actual elephant as an exercise for their graduate students.

COMPUTER SCIENTISTS: hunt elephants by exercising Algorithm A:
1. Go to Africa.
2. Start at the Cape of Good Hope.
3. Work northward in an orderly manner, traversing the continent alternately east and west.
4. During each traverse pass,
1. Catch each animal seen.
2. Compare each animal caught to a known elephant.
3. Stop when a match is detected.

EXPERIENCED COMPUTER PROGRAMMERS: modify Algorithm A by placing a known elephant in Cairo to ensure that the algorithm will terminate.

ASSEMBLY LANGUAGE PROGRAMMERS: prefer to execute Algorithm A on their hands and knees.

ENGINEERS: hunt elephants by going to Africa, catching gray animals at random, and stopping when any one of them weighs within plus or minus 15 percent of any previously observed elephant.

ECONOMISTS: don't hunt elephants, but they believe that if elephants are paid enough, they will hunt themselves.

STATISTICIANS: hunt the first animal they see N times and call it an elephant.

CONSULTANTS: don't hunt elephants, and many have never hunted anything at all, but they can be hired by the hour to advise those people who do.

OPERATIONS RESEARCH CONSULTANTS: can also measure the correlation of hat size and bullet color to the efficiency of elephant-hunting strategies, if someone else will only identify the elephants.

POLITICIANS: don't hunt elephants, but they will share the elephants you catch with the people who voted for them.

LAWYERS: don't hunt elephants, but they do follow the herds around arguing about who owns the droppings.

SOFTWARE LAWYERS: will claim that they own an entire herd based on the look and feel of one dropping.

VICE PRESIDENTS OF ENGINEERING, RESEARCH, AND DEVELOPMENT: try hard to hunt elephants, but their staffs are designed to prevent it. When the vice president does get to hunt elephants, the staff will try to ensure that all possible elephants are completely prehunted before the vice president sees them. If the vice president does happen to see a elephant, the staff will:
1. compliment the vice president's keen eyesight and
2. enlarge itself to prevent any recurrence.

SENIOR MANAGERS: set broad elephant-hunting policy based on the assumption that elephants are just like field mice, but with deeper voices.

QUALITY ASSURANCE INSPECTORS: ignore the elephants and look for mistakes the other hunters made when they were packing the jeep.

SALES PEOPLE: don't hunt elephants but spend their time selling elephants they haven't caught, for delivery two days before the season opens.

SOFTWARE SALES PEOPLE: ship the first thing they catch and write up an invoice for an elephant.

HARDWARE SALES PEOPLE: catch rabbits, paint them gray, and sell them as desktop elephants.

"You gave us bad code! We ran it and now production is DOWN! Join this bridgeline now and help us fix this!"

So, as the author of the code in question, I join the bridge... And what happens next, I will simply never forget.

First, a little backstory... Another team within our company needed some vendor client software installed and maintained across the enterprise. Multiple OSes (Linux, AIX, Solaris, HPUX, etc.), so packaging and consistent update methods were a a challenge. I wrote an entire set of utilities to install, update and generally maintain the software; intending all the time that this other team would eventually own the process and code. With this in mind, I wrote extensive documentation, and conducted a formal turnover / training season with the other team.

So, fast forward to when the other team now owns my code, has been trained on how to use it, including (perhaps most importantly) how to send out updates when the vendor released upgrades to the agent software.

Now, this other team had the responsibility of releasing their first update since I gave them the process. Very simple upgrade process, already fully automated. What could have gone so horribly wrong? Did something the vendor supplied break their client?

I asked for the log files from the upgrade process. They sent them, and they looked... wrong. Very, very wrong.

Did you run the code I gave you to do this update?

"Yes, your code is broken - fix it! Production is down! Rabble, rabble, rabble!"

So, I go into our code management tool and review the _actual_ script they ran. Sure enough, it is my code... But something is very wrong.

More than 2/3rds of my code... has been commented out. The code is "there"... but has been commented out so it is not being executed. WT-actual-F?!

I question this on the bridge line. Silence. I insist someone explain what is going on. Is this a joke? Is this some kind of work version of candid camera?
Finally someone breaks the silence and explains.

And this, my friends, is the part I will never forget.

"We wanted to look through your code before we ran the update. When we looked at it, there was some stuff we didn't understand, so we commented that stuff out."

You... you didn't... understand... my some of the code... so you... you didn't ask me about it... you didn't try to actually figure out what it did... you... commented it OUT?!

"Right, we figured it was better to only run the parts we understood... But now we ran it and everything is broken and you need to fix your code."

I cannot repeat the things I said next, even here on devRant. Let's just say that call did not go well.

So, lesson learned? If you don't know what some code does? Just comment that shit out. Then blame the original author when it doesn't work.

You just cannot make this kind of stuff up.