Where has the FUD gone?

A long time ago, the IT industry was subjected to FUD (Fear, Uncertainty, Doubt) advertising campaigns.

FUD was a marketing strategy used by IBM. When competitors announce a new product (or worse, a breakthrough product), IBM would announce a similar product, but only in broad terms. The idea was to encourage people to wait for IBM's product, thereby reducing sales of the competing product. (It also created hype for the IBM product.)

To be effective, a FUD announcement had to describe a future product. It created doubt and uncertainty, and fear of making a bad choice of technology.

I haven't seen a FUD announcement for a long time.

They were common when IBM was the dominant manufacturer for computing equipment. The FUD campaign may have ended shortly after the introduction of the PS/2 (itself a product with a FUD announcement) line of computers. The market rejected the PS/2's Micro Channel Architecture, and accepted Compaq's ISA (the old PC standard architecture) with its 80368 processors. (Although the market did adopt IBM's VGA display and 1.44 MB hard "floppy" disk as standards.)

Compaq didn't use FUD announcements to take the lead from IBM. It delivered products, and its announcements for those products were specific. The message was "our products have this technology and you can buy them today".

There is one company today which has something similar to FUD announcements. But they are different from the old-style FUD announcements of yesteryear.

That company is Apple.

Apple is the one company that announces future products. It does it in a number of ways, from its annual marketing events to its reliable product schedule. (Everyone knows that Apple releases new iPhones in September, for example.)

Apple's FUD campaign seems to be accidental. I don't think that Apple is playing the same game that IBM played in the 1980s. IBM made FUD announcements to deter people from buying products from other companies. Apple may be doing the same thing, but instead of affecting other companies, I think it is Apple itself that suffers from these announcements.

Apple announcing a new processor for its MacBook line doesn't deter people from buying Windows laptops. They need laptops, they have already chosen Windows (for whatever reason) and they are going to buy them. Very few people change their purchasing decision from Windows to a yet-to-be-defined MacBook.

But a lot of Apple users defer their purchases. Many Apple users, in the middle of planning an upgrade, put off their purchase until the new MacBook was released.

Trade publications advise people to defer the purchase of Mac Minis, based on Apple's announcements and regular product schedule.

This behavior is the same as IBM's FUD from thirty years ago -- but with the difference that the (unintentional) target is the company itself.

It may be that Apple is aware of customers deferring their purchases. Perhaps Apple wants that behavior. After all, if Apple withheld new product information until the release of the product, those who recently purchased the older version may feel betrayed by Apple. It may be that Apple is forgoing immediate revenue in exchange for customer goodwill.

I'm happy to live in a world without FUD announcements. The IT world with FUD has challenges for planning, and a constant fear of missing out on important technology. The current world is a much more relaxed place. (That may sound odd to technology managers, but believe me, today's world is much better than the older one.)

E-mail Addresses Considered Harmful

PCWorld lost (temporarily) their YouTube account because their e-mail address changed.

YouTube, like many web services, uses e-mail addresses for customer IDs. This, I think, is a poor practice.

Many web services and many cloud services create dependencies on an email address. Your account ID is your email address. (This is a cheap way to ensure unique IDs.) When updating my e-mail address on these sites, I am changing my ID.

IDs should be unique, short, and permanent. E-mail addresses are unique, and they are usually short, but they are not permanent. E-mail addresses can change. Specifically, e-mail addresses can change outside of the control of the organization that uses them as IDs. I changed my main e-mail address recently, and had to go through all of my accounts (I keep a list) and update each of them.

For most sites, I was able to change my e-mail address. Some sites let me change my contact e-mail address but did not allow me to change my ID. Those sites send e-mails to my new address, but I must use my old e-mail address to log in. Other sites let me change my e-mail address as ID, but kept sending notifications to my old e-mail address. (Their web site stores the e-mail addresses for notifications as a copy of the login ID, and those e-mail addresses are not updated when the ID is changed.)

Clearly, different web sites have different ideas about the separation of ID and e-mail.

Companies running web services, or cloud services, should carefully select their IDs for customers. How do they use those IDs? Are they stored in databases? Are they keys in databases? If a customer changes their e-mail address, what happens to the records with the old e-mail address? How does a new e-mail address affect queries? Do the two e-mail addresses appear as two different customers?

This is why database keys (and user IDs) should be unique and permanent.

Banks and insurance companies understand this. I am a customer to a few insurance companies and several banks. All of them -- without exception -- use their own IDs for my account. Not email addresses.

The underlying concept here is ownership. When I open an account with a bank and they ask me to provide an ID (not an e-mail), they are really asking me to pick an ID from a (very) large set of unused IDs that conform to their rules (so many letters and digits). I pick the ID, but they own it. They can change it if they want. (I've never seen that happen, but it could.) And if they change it, nothing else in my electronic life changes.

An e-mail address, in contrast, is owned by the e-mail provider (GMail, Yahoo, Microsoft, etc.). I don't own it, I merely "rent" it. Anyone I give it to, either a friend, colleague, or web service, is only borrowing it. It can be withdrawn from circulation at any time, either by me or the e-mail service.

Building a service on data that you don't own is risky. I understand the appeal of e-mail addresses as IDs. (It is easy, everyone else does it, it doesn't require our own code to create new IDs for customers, and anyway customers don't want another ID for our service and that is a disincentive for them to use our new service so use the e-mail addresses because the folks in marketing want it that way.)

Yet I must balance those appealing factors with the risks. For individuals, the e-mail address may be an acceptable ID. For corporate accounts, e-mail addresses as ID pose risks to the customer. (Just as PCWorld.)

In essence, using e-mail addresses as IDs is simple for the service, but imposes risks on customers. That may not be the best of business practices.

Eggs and baskets

PCWorld, a venerable trade publication-now-website of the IT realm, recently lost its YouTube video channel. The channel was disabled (or suspended? or deleted?) and no content was available. For more than eight days.

From what I can discern, IDG's YouTube account was controlled by an IDG e-mail address. Everything worked until IDG was purchased by Foundry, and Foundry changed all of IDG's e-mail addresses to Foundry addresses, didn't change the account at YouTube, and YouTube, seeing no activity on the IDG e-mail address or maybe getting bounce messages, cancelled the account.

Thus, the PCWorld video channel was unavailable for over a week.

Why didn't PCWorld restore its channel? Or make its content available on another service? 

My guess is that IDG stored all of their video content on YouTube. That is, the only copy was on YouTube. IDG probably relied on YouTube to keep backup copies and multiple servers for disaster recovery. In short, IDG followed the pattern for cloud-based computing.

The one disaster for which IDG failed to prepare was the account cancellation.

I must say here that a lot of this is speculation on my part. I don't work for PCWorld, or at IDG (um, Foundry) or at YouTube. I don't know that the sequence I have outlined is what actually happened.

My point is not to identify exactly what happened.

My point is this: cloud solutions, like any other type of technology, can be fragile. They can be fragile in ways that we do not expect.

The past half-century of computing has shown us that computers fail. They fail in many ways, from physical problems to programming errors to configuration mistakes. Those failures often cause problems with data, sometimes deleting all of it, sometimes deleting part of it, and sometimes modifying (incorrectly) part of the data. We have a lot of experience with failures, and we have built a set of good practices to recover from those failures.

Cloud-based solutions do not eliminate the need for those precautions. While cloud-based solutions offer protection against some problems, they introduce new problems.

Such as account cancellation.

Businesses (and people, often), when entering into agreements, look for some measure of security. Businesses want to know that the companies they pick to be suppliers will be around for some time. They avoid "fly by night" operations.

A risk in cloud-based solutions is account closure. The risk is not that Google (or Oracle) will go out of business, leaving you stranded. The risk is that the cloud supplier will simply stop doing business with you.

I have seen multiple stories about people or businesses who have had their accounts closed, usually for violating the terms of service. When said people or businesses reach out to the cloud provider (a difficult task in itself, as they don't provide phone support) the cloud provider refuses to discuss the issue, and refuses to provide any details about the violation. From the customer's perspective, the results are very much as if the cloud provider went out of business. But this behavior cannot be predicted from the normal signal of "a reliable business that will be around for a while".

It may take some time, and a few more stories about sudden, unexplained and uncorrectable account closures, but eventually people (and businesses) will recognize the risk and start taking preventative actions. Actions such as keeping local copies of data, backups of that data (not local and not on the main cloud provider), and a second provider for fail-over.

In other words:

Don't put all of your eggs in one cloud basket.