Wednesday, July 18, 2012

It Depends; and with Linux It Depends Even More

Does anyone know who David Bradley is? He's the one of the designers on the original IBM PC who designed Control+Alt+Delete to trigger a soft reboot. His line that captured his 15 minutes of fame was:
"I may have invented Control-Alt-Delete, but Bill Gates made it famous."
I didn't invent "It Depends". I actually first heard it from Marty Zimelis when he was with Amdahl doing education. I believe it was rule number one on his list of Performance Analyst Rules. (I need to find and post the other ones). But I know some people think I own the royalties on it. When Linux came on the scene, I did add the "with Linux it depends even more."

Now, I know some people consider "It Depends" to be a cop out or a way to avoid answering a question. I don't mean for it to be that. It's really just a preamble for me which translates into:
Be careful, there is not necessarily a single or unqualified answer to your question. I am going to ask you to think about some things and understand the environment and factors that play in that environment. I will be very sad if you just take one aspect of what I say and run off and misuse that information. If my response involves a range of values, you need to know why the answer may lean towards one or the other end of that range.
As you can imagine, it's much easier to say "it depends" than the above. Some of you have caught on and after hearing "it depends", ask what are the dependencies?

At some point in my career, I was faced with the reality that there are a set of people out there that actually listen to what I say. I became more aware of the idea that what I said had weight. I began to be more cautious about giving absolutes, and quicker to point out whether what I was sharing was conjecture, provable, or proven fact. Being clear on the difference of those has become very important to me in problem determination.

I've been in situations with major problems. Then Jimmy will say something in the hallway such as,  "I wonder if it's the network?".  Some listener will repeat it as "Jimmy thinks the problem is the network.", which becomes "Jimmy identified the problem as the network."  Heavy sigh.

I often hear that z/VM or System z is too complex or difficult. And I often think, compared to what? I've never met anyone of average intelligence that had trouble navigating around the CMS environment and editing in a week or two; writing useful REXX scripts in a month; understanding the fundamentals of z/VM system programming in a few months. I hear the 3270 is too difficult. Seriously? It's the same keyboard as every other system, just less mousing. I lose this argument a lot with some people. Oh well.

(I'd really like to see a study on the ratio of time spent typing vs. clicking for the average z/VM system programmer, Linux Admin, and Windows Server Administrator. My conjecture is that the ratios would be closer than some people believe.)

Please don't get me wrong. I'm all for simplification. However, there's a difference between putting a GUI frontend on SET SRM values and simplification. What we want to avoid is eye candy for sake of eye candy; and making it simpler to screw up the system.

I always had trouble putting my finger on why some people seem to have so much trouble with Linux on z/VM. Until one day, Steve Gracin from IBM ATS gave me the answer. "It doesn't matter what system or interface you're using, you have to know what you're doing." And in some cases, we're just not willing to learn that. (See early blog entries about the value of mentors and community). And in other cases, we're not willing to admit we don't understand. Most systems that do significant things are complex and therefore, it's our jobs to understand aspects of the system.

So back to "it depends". Often, that's the start of thinking about what factors come into play. What objectives are there? The beauty of Linux is that it is so flexible; the challenge of Linux is it is so flexible. I work with customers running 256MB virtual machines and virtual machines over 100GBs. What is right for one, may be wrong for the other. And someone needs to think about the difference. Understanding the dependencies of ones system is a key aspect to knowing what you're doing. And if you want a job where thinking isn't required, I suggest systems programming, on any platform, is not for you.

Customers, you should know you're not the only ones I give the "it depends" line. Inside, I do the same thing in planning and design meetings. A new solution or line item is proposed and I know it will have different degrees of benefit for different customers. The answer to "what is the benefit to the customer?" is "it depends". Now, what are those factors. Understanding those, helps us to understand the scope of benefit to customers and the return on the risk. Some of our less successful ventures have been where we built everything and then asked the question.

So I hope you all have a better appreciation for what's behind "it depends".

1 comment:

  1. The "Rules of Performance"
    1. Performance analyst's number one answer is, "It depends."
    2. "If you can't measure it, I'm not interested." (Corollary: "If you can't measure it, it didn't happen.")
    3. Any change you make will have unanticipated side effects.
    4. It doesn't work the way you think it does.
    5. When in doubt, blame it on network delays.
    6. When cornered, preface your response with "According to the Queuing theory..." Your audience won't admit that they don't understand either.

    ReplyDelete