Management Rules That Make No Sense #12: Its Magic

You know that bug I told you about?

The one that randomly printed people’s names in reverse?

Yeah. I fixed it.

Oh?

Well, I kept thinking the problem had to be in the data store, right? But why would the string field for person.name.last in the data store only screw up sometimes, you know? So, I started looking at my other classes and I realized that when I had to process a name that included a double byte character, I was calling the string parser, and you remember I had to rewrite my own parser because the included one couldn’t handle mixed double byte and standard ASCII chars? Well anyway, I wasn’t resetting that variable I passed it to tell it I had a doublebyte string. And when I passed it a second time, the value just happened to be large enough to force a record size check, which of course I did back to front since I had a pointer to the final char in the list, and could simply count backwards. So, a simple initialize statement before I call for input and the problem is solved! Isn’t that cool?

Huh? I kind of quit listening after you said “I fixed it.”

One of the most boring things in the world is to hear a programmer describe fixing a bug in a program you’ve never worked on. The weird thing is that to the programmer herself, it really is fascinating. You can spend hours combing through your code checking and rechecking your logic to try to find the source of an elusive bug. When you do finally find the error, it’s often something simple; a transposed number, or a simple typing mistake. To you, it’s the culmination of hours of hunting. To other people it’s really, really boring.

Incidentally, do you know why we call them bugs? It’s all because of one of the founders of Computer Science, Grace Hopper.

(Photo credit: Wikipedia)

Rear Admiral Hopper was a computer programmer back when computers took up an entire room and did less than your phone apps do today. The relays back then were electrical, and mechanical, not electronic. So, there were metal levers that opened and closed to make connections.

One day there was a problem with the program. It didn’t run correctly. Admiral Hopper opened up the big side panels and inside discovered that a moth had flown in between the contacts on one of the mechanical relays. She taped the moth into her log book and documented the first computer “bug.”

First computer “bug” (Photo Credit: Wikipedia)

See? Computer Scientists aren’t ALWAYS boring. But, most of the time they are. It’s strange too, because most programmers and engineers love to talk about systems and programs. It really is a foreign language. In fact, it’s multiple foreign languages, there is an entire lexicon of various computer languages, (C, C+, C#, Ruby, Python, BASIC, COBOL (written by Admiral Hopper in the 1950’s and still in use today.))

You might be tempted to look at today’s Management Rule That Makes No Sense title, “It’s Magic” and think it’s better to simply take the work programmers and engineers do as magic and not try to understand it.

That’s probably a reasonable approach, but it’s not what the rule actually means. If a technical person is giving an answer to a non-technical person, they will give their answer in one of two ways depending on their goal. If they want to actually explain what they’ve done, they will attempt to “translate” tech-speak into more intelligible language. They will most likely resort to analogies.

For example, you’ve probably heard of TCP/IP, but may not know what it refers to except that it has something to do with the internet. An IP address is kind of like your house number. Every house in your town has a unique address. Every computer on your network has a unique IP address. It’s how computers know how to keep track of each other. TCP refers to how the information is moved. Kind of like the idea that letters addressed to your house will be delivered by the postal worker. TCP describes how the computers route information back and forth.

That’s one way a techy person might explain technical terms if they trying to give you actual information. If the techy person simply wants you to go away and let them get back to playing with their shiny software toys, they will swamp you with jargon and then ignore you.

The IP protocol is a set of four octets that unique identify every device in a network. Octets support values of 0-255. Addresses are divided into class A, B and C addresses that correspond to each Octet. Routers route data packets based on the values in the octets.

They’ll keep going until you give up and leave in frustration, which is what they wanted in the first place. But, that’s not why this rule is called “It’s Magic.”

When explaining a technical solution to another technical person, sometimes the worst thing you can do is actual explain the technical details. You risk having the person you are explaining your solution to giving you completely unsolicited feedback.

Why not simply initialize the variable when you first load the program and then have the last command of each process reinitialize it?

Why? Because I choose to do it THIS way! You may not want to go through an architecture review simply so that you can give a status update to a coworker.

The other danger of giving a technical answer is more subtle. I was the email administrator for a large 30,000 user non-profit organization. I had discovered a clever way of calculating which users needed a larger mailbox. My algorithm, which I called the “Efficiency Index” looked at the how full a mailbox was, how much email had recently been deleted and how much new email the user got. I maintained it in an Excel spreadsheet and it took about 10 minutes for my laptop to churn through the calculations each morning.

I was explaining the Efficiency Index to the manager of our database team. There was no way for him to know what his EI number was on a daily basis. But, I explained the logic of it to him anyway. A couple weeks later I bumped into him again.

Rodney, can you tell me what my efficiency index is for the past week?

Why? You already have a large mailbox. If you need more space let me know and we can accommodate you. Your efficiency index won’t mean anything to you.

I know, I know. But, ever since you explained how you calculate it, I’ve been thinking about my mailbox, and I think I’ve figured out how to get a high efficiency index number. I know it doesn’t matter, but now I’m intrigued.

I just shook my head. It occurred to me that sometimes the best answer to a technical question is: It’s magic.

Rodney M Bliss is an author, columnist and IT Consultant. He lives in Pleasant Grove, UT with his lovely wife and thirteen children.

Follow him on
Twitter (@rodneymbliss)
Facebook (www.facebook.com/rbliss)
LinkedIn (www.LinkedIn.com/in/rbliss)
or email him at rbliss at msn dot com