Who's Your Data?

Random thought of the day: on a recent Sopranos episode Tony Soprano called message boards, chit-chat sites. I loved that.

There has been a lot of chit-chat on the web about how much money American engineers make overseas. There are thousands of US engineers in the Middle East, Asia and Europe. The salaries I have heard thrown around are $200k to $250k a year.

Last week I talked to 5 engineers stationed overseas. I believe I got to the bottom of the story…the rest of the story, Good day. As usual there is less to the wild stories about money and compensation than meets the eye.

Engineer A is stationed in a secret location in Asia. Although I don’t know how secret it is, he told me. He is a mid-level engineer who works with Windows based systems and some telco gear. He has about seven years of industry experience. He was trained in IT by the military and has that important Top Secret/SCI/BBKING/REM clearance.

BTW – Since it is a secret I thought about giving Engineer A the alias of Mr. Pink for this blog– I saw Reservoir Dogs last week. I watched it on my video ipod on the plane. All of the bad guys are named after a color. As it got more and more violent I cupped my hands closer to the screen so the Mother with the two little babies sitting next to me didn’t lose it. That’s one of those movies where you can accurately say…everybody dies in the end.

I digress. Mr. Pink, uh Engineer A, makes $200k a year. Wow! Case closed. He is about a $60k a year engineer in Colorful Colorado and about an $80k guy in DC. It seems he is making a lot of money in Korea (oops, so much for the secret location). Until…I asked a few more questions. How many days a week do you work? All of them. Weekends? Yup. How many hours a day? Ten. What? Seven days a week, ten hours per day? That’s, wait a minute…seventy hours a week. That’s 3640 hours of work a year. Divided by $200k a year, that’s about $55.00 an hour. For a normal DC engineer that would be equivalent of roughly $115k a year. A premium, but not as wild as it first sounds.

Engineer A tells me that there is absolutely nothing else to do where he is located but work. His wife (no children) is in New York. He hasn’t seen his Mom or Dad in two years. Engineer A and the others I talked to are ready to come back to the states. Engineer A was hoping to make $150k in DC, New York or Boston. The best offer he is getting in the US is for about $90k. Mr. Pink is feeling blue.

Posted by Matt Hamilton at 12:11 PM | | Permalink | Comments (1491) | TrackBacks (0)

A good friend of mine travels frequently for business. He has a laptop and a blackberry for email and cell phone access. Whenever he travels he changes his email and voicemail messages to state that while he is traveling he will have “limited access to email and phone messages, but will endeavor to return your call upon his return”!

I have asked him why he has all of these mobile communication devices if he doesn’t endeavor to return messages while he is on the road! He told me a dirty little secret…he gets 100+ emails a day and 10 to 20 voicemails. He has an assistant to help, but still must reply to most of the messages himself. The road has become his refuge and he uses this system to get away from all of the noise.

I wonder how many people are using technology to get away from technology. That calls into question a lot of the productivity gains we tout for mobile communication devices. On the other hand…there are an awful lot of people talking to themselves in airports. I thought the cell phone with ear plug was an annoying development. There is nothing worse than the Bluetooth ear piece. At least until we invent something worse.

I miss The Brick; the mobile phone in the early 80’s that announced its presence at the lunch table for all to see. You couldn’t not see The Brick. I did have to scream into it to be heard in the four spots in downtown Denver where you could get reception. No one I knew ever took The Brick on the road. We used an ancient technology called a land line. A few years later my colleagues were carrying these slick Motorola StarTac phones. They flipped open, of all the damn things! I had a clunky…whatever the store was selling phone. Now I have a Blackberry, but I am still behind the curve. My Blackberry is fatter than my friend’s who never answers his on the road. I feel so empty.

One thing I can promise you, if I am on the road with my outdated Blackberry I will endeavor to return your call when I am safely back home again.

Posted by Matt Hamilton at 10:30 AM | | Permalink | Comments (11) | TrackBacks (0)

Math is supposed to communicate concepts in a straight-forward and concrete way, right? Fat chance! Just ask an economist to interpret the recent non-GAAP numbers for company X and you will likely get an earful for an hour or two about how they can make the numbers say anything they want. Well, the same is true for some of the math we're seeing in the new de-duplication technologies.

Some definitions might be helpful. De-duplication is the process of eliminating redundant files, bytes or blocks of data to ensure that only the ‘unique’ files, bytes or blocks are stored. On a file level, this might be single instance store. For example, if a user sends a PowerPoint presentation to 15 people, then single instance store would only keep one copy of the file and use pointers as a reference for everyone else to access that file. A very rough byte or block level de-duplication example might be to take that same PowerPoint file, split it up into unique byte or block level "chucks" and then use pointers to rebuild that file when necessary. Why is this appealing? Well, you can imagine that one of those unique "chunks" from the PowerPoint presentation might also be present in hundred's of other files. You are no longer dependent on the file or even file types, but can reference these unique chucks from within all file types. Still with me?
The Math:
De-Duplication hardware and software vendors are coming up with some fairly amazing numbers. De-duplication is proposing data reduction of 10:1, 20:1 and even up to 100:1 or MORE! Is this possible? Is it all lies? Well, no, not exactly. :-) The numbers are possible given the right scenario.
You CAN handle the truth!:
So, what is the truth? The truth is that a lot of factors play into what kind of data reduction you will achieve. Full versus incremental backups, retention, compression, de-duplication within the backup itself, daily rate of data change; all of these factors come into play. You might see a 30:1 reduction or better. You might see 6:1. In comparison to 2:1 compression on tape, 6:1 is still an amazing reduction in data. The best possible scenario for de-duplication is in the area of backups since this data tends to be highly redundant from one backup to the next and especially between full backups. Think about it, how much data is actually changing between those weekly full backups? 1%? 10%? Even 50% means that you are still backing up 50% redundant data. The potential gain in cost savings from reduction in backup data is very appealing to many customers. Think of the cost savings if you can store 20TB of backup data on only 1TB of disk! Think not only about the hardware costs, but data center cooling, administration costs, power consumption; it all saves money! What needs to be done is to explain de-duplication ratios so that they we don't get caught up in the numbers hype.
OK, stick with me on this. If you were to do a full back up of XGB of data for 30 days and that data never changed, then you would end up with a de-duplication ratio of 30:1. Why? Because you sent 30 days of backup data, but 29 days of that data weren't needed or stored because it was all redundant! Still with me? Obviously if you did this for 100 days you would end up with 100:1 reduction. See, it is possible. :-) Now let me ask you, how many of you do a full back up, every night, of completely unchanging data? I have yet to meet one company that does. Yes, we all want to get 100:1 reduction, but what are the problems you are trying to solve? What if de-duplication presented a working solution for your need, but did it with a 5:1 de-duplication ratio? Would you care about the ratio or the fact that you solved your particular problem and need?
Conclusion:
Know your need FIRST, get all the facts from a trusted technologist and then find the tool that meets your need. Don't get sucked in by some company that claims that their product will solve all of your problems. Some of these companies are a one trick pony. They try to make everyone's problem look like a nail to their hammer. Remember, some of these companies said that tape backups would be gone 5 years ago and yet, tape is still going strong. Do the research, find a trusted advisor, and put together a holistic solution that meets your needs! De-duplication may be a great asset to your organization or it might be a cool technology that doesn't quite fit your needs!

Still have questions? Post them here!

Posted by Matt Divens at 10:26 AM | | Permalink | Comments (1282) | TrackBacks (0)

A customer asked me why Brand X software was so buggy. I told him that if the computer industry waited until all software was de-bugged before release, we would never have released NT, Exchange, Windows Server 2003 or Vista.

Of course, I have colleagues who believe that would have been a monumental achievement. Personally, I find cheap jokes at Redmond’s expense to be…cheap. That doesn’t mean I won’t tell them. I just feel very dirty afterwards. The fact is all software is buggy. It’s almost like the term buggy is a misnomer. All software, in fact all of life, is a work in progress. Wow. That was heavy.

Perhaps we should call Bugs something different. How about “new insights” or “unexplained phenomena”? The problem is that those darn human beings are writing the millions of lines of code that go into a new software release. As much as we train them they appear to be subject to…human error. If you have ever looked at a page full of software code with all the dots, dashes, colons, imperators (?) spaces, slash throughs and underlines you would wonder how any software ever gets released.

Someone clearly needs to think outside the programming box and come up with a better language for programming (Bill Joy just fell off his think tank in Aspen). Until they do we are stuck with…C+-#_666/antichrist=f9* ct M #@%...or some such gobbledygook.

We tell customers to wait for a couple of maintenance packs to arrive before they upgrade to the next major release unless there are features or security issues addressed. Don’t upgrade because “we always like to be at the vendor’s latest version”. Do you like working weekends? Have you ever had to “go back a rev” to keep your enterprise running? It is not fun.

Instead of worrying about those pesky little bugs, focus on the big picture. Redmond is releasing their next Office upgrade!

Posted by Matt Hamilton at 09:20 AM | | Permalink | Comments (571) | TrackBacks (0)