Chris on December 31st, 2009

If your company seems evil, the best programmers won’t work for you. That hurt Microsoft a lot starting in the 90s. Programmers started to feel sheepish about working there. It seemed like selling out. When people from Microsoft were talking to other programmers and they mentioned where they worked, there were a lot of self-deprecating jokes about having gone over to the dark side. But the real problem for Microsoft wasn’t the embarrassment of the people they hired. It was the people they never got. And you know who got them? Google and Apple. If Microsoft was the Empire, they were the Rebel Alliance. And it’s largely because they got more of the best people that Google and Apple are doing so much better than Microsoft today.

Why are programmers so fussy about their employers’ morals? Partly because they can afford to be. The best programmers can work wherever they want. They don’t have to work for a company they have qualms about.

But the other reason programmers are fussy, I think, is that evil begets stupidity. An organization that wins by exercising power starts to lose the ability to win by doing better work. And it’s not fun for a smart person to work in a place where the best ideas aren’t the ones that win. I think the reason Google embraced “Don’t be evil” so eagerly was not so much to impress the outside world as to inoculate themselves against arrogance. [1]

via Apple’s Mistake.

Chris on December 2nd, 2009

Opinion: The unspoken truth about managing geeks.

Good IT pros are not anti-bureaucracy, as many observers think. They are anti-stupidity. The difference is both subjective and subtle. Good IT pros, whether they are expected to or not, have to operate and make decisions with little supervision. So when the rules are loose and logical and supervision is results-oriented, supportive and helpful to the process, IT pros are loyal, open, engaged and downright sociable. Arbitrary or micro-management, illogical decisions, inconsistent policies, the creation of unnecessary work and exclusionary practices will elicit a quiet, subversive, almost vicious attitude from otherwise excellent IT staff. Interestingly, IT groups don’t fall apart in this mode. From the outside, nothing looks to be wrong and the work still gets done. But internally, the IT group, or portions of it, may cut themselves off almost entirely from the intended management structure.


Chris on October 13th, 2009

AppleInsider | Microsoft’s Sidekick/Pink problems blamed on dogfooding and sabotage.

The article posits two questions: Was MSFT trying to pull a hotmail and convert the service to its own products (like it did in the 90s when it converted the stable Unix Hotmail infrastructure to NT4) or was it sabotage by a disgruntled employee.

I think it would be pretty damn hard to corrupt the systems, corrupt the data, and corrupt all the backups to the point that recovery isn’t possible. On the other hand MSFT acquired this company and the company had technologies vastly different than MSFT’s core competencies. Its quite possible the original engineers could recover the service and data, while the MSFT people cannot.

As this older article on the subject points out:

Microsoft’s accountability in supporting its acquired Sidekick support obligations with T-Mobile was also shirked. The source stated that “apparently Microsoft has been lying to them [T-Mobile] this whole time about the amount of resources that they’ve been putting behind Sidekick development and support [at Danger] (in reality, it was cut down to a handful of people in Palo Alto managing some contractors in Romania, Ukraine, etc.). The reason for the deceit wasn’t purely to cover up the development of Pink but also because Microsoft could get more money from T-Mobile for their support contract if T-Mobile thought that there were still hundreds of engineers working on the Sidekick platform. As we saw from their recent embarrassment with Sidekick data outages, that has clearly not been the case for some time.”

It seems pretty clear that no matter what happened, the fault rests with Microsoft Management.

Chris on October 11th, 2009

So it seems like the anti-cloud fanatics are all popping open beers in celebration of MSFT’s failure to restore user data for T-Mobile’s sidekick.

I’m not sure I’d blame clouds, cause I’m not sure I’d consider that T-Mobile service a cloud to begin with. Unless you consider your IMAP box at your ISP a cloud, or your corporate exchange server a cloud, or wiki a cloud. Sidekick is a service. Services go down. Sometimes service providers cut corners and don’t hire enough staff so that the admins can test a restore of the backups created.

The anti-cloud people are telling to to keep all your data locally. On your single consumer grade hard drive. That is subject to residential power spikes and dips. That is never backed up because (unless your an OSX user with Time Machine) it is a pain-in-the-ass to do backups. That even if it is backed up, it is put on a shelf in the same building as your original copy.

Yes, this was a clusterf–k of massive proportions. And so it made news. But how many people lose all the family pictures because their house was flooded and the hard drive and backup CDR/DVD-Rs washed away too? How many people lose all their data because they drop their laptop and the harddrive crashes? or lose their data because burgers stole their PC?

Even in the corporate world, one has to consider that cloud-like service providers are better. In a small company, or company with a small IT shop, how often do you check your backup tapes to make sure they are readable? How much do you pay to Iron Mountain to store the data offsite. How good is your monitoring of your Raid-Array to know when a drive fails? (I discovered this one first hand at StayOnline).

As in everything Caveat Emptor. Know who your cloud/service provider is. Do they compete on price or service? Recall that you get what you pay for and if they are a bargain basement provider, they probably hire bargain basement staff who may or may not know the number 1 rule of backups is to test your restore process. If you’re a small or large company, demand to see their DR plans prior to moving your critical business processes into their cloud. And, as the previous administration learned, have an exit strategy, because at the end of the day _you_ are responsible for your decisions and if you fuck up and go with the wrong vendor, you will be held accountable by the executives, who will be held accountable by the shareholders and customers.

Tags: , ,