That Cringely rumor

Robert X. Cringely has predicted mass layoffs at IBM:

To fix its business problems and speed up its “transformation,” next week about 26 percent of IBM’s employees will be getting phone calls from their managers. A few hours later a package will appear on their doorsteps with all the paperwork.

I wouldn’t normally write about this kind of thing, but a lot of news sources have taken the rumor and republished it as if it is fact, and people I know are starting to believe it. Apparently the media are unaware that Cringely has a history of predicting IBM doom.

So, before you get too excited about the current rumor, let’s take a look at a couple of Cringely’s previous predictions. Here’s one from 2007:

The BIG PLAN is to continue until at least half of Global Services, or about 150,000 workers, have been cut from the U.S. division. […] All this is supposed to happen by the end of 2007, by the way.

IBM did not, in fact, cut 150,000 US employees in 2007. IBM had around 117,000 US employees in 2006 and around 121,000 US employees at the end of 2007, so the company didn’t even have 150,000 US employees to cut, let alone 150,000 in Global Services.

Or consider Cringely’s 2012 prediction:

The direct impetus for this column is IBM’s internal plan to grow earnings-per-share (EPS) to $20 by 2015. The primary method for accomplishing this feat, according to the plan, will be by reducing US employee head count by 78 percent in that time frame.

I don’t have numbers, but I am pretty sure IBM did not, in fact, cut US head count by 78% between 2012 and the start of this year. That’s the kind of thing I’d have noticed.

So… When you read stories about IBM, check the source. And if it’s Robert X. Cringely, apply a heaping serving of salt.

(Disclaimer: I have no inside knowledge of what IBM management are planning for 2015. Opinions are mine, not IBM’s.)

A REST Web Service antipattern: The 200 black hole

If you haven’t yet gotten around to implementing an API call on your Web Service, do not make it return HTTP 200 OK. Instead, return 501 Not Implemented.

If you return 200 OK but your code does nothing, the caller is likely to assume that he made some kind of error performing the call, and could easily spend an entire afternoon trying different payload and parameter encodings and tracing code internals.

The other end of the POODLE

I’ve written about how to front-end your Domino servers with Apache to provide TLS up to TLS 1.2 and block SSLv3. But what about the other side of the problem? You might not be able to upgrade your Java runtime easily, particularly if you’re using IBM XPages.

Well, fortunately life is easier on the consumer side of Web Services. There are some system properties which let you enable TLS on earlier Java runtimes where it’s disabled by default. It’s harmless to set them on Java 8.

There are different settings for IBM JRE and Oracle JRE, so I just set both in my code before making any HTTPS connections.

// Set properties for secure TLS on Oracle JRE 6 and 7
System.setProperty("deployment.security.SSLv2Hello", "false");
System.setProperty("deployment.security.SSLv3", "false");
System.setProperty("deployment.security.TLSv1", "false");
System.setProperty("deployment.security.TLSv1.1", "true");
System.setProperty("deployment.security.TLSv1.2", "true");
System.setProperty("jsse.enableSNIExtension", "false");
// This one is for IBM JRE 6 and 7
System.setProperty("https.protocols", "TLSv1.2,TLSv1.1");

The SNI Extension disabling is to fix “SSLProtocolException: handshake alert: unrecognized_name” caused by lack of SNI support in our SSL certificates. (The vendor we’re required to use doesn’t support it yet.) If you have SNI, you can leave that one out.

Maybe I’m crazy, but I develop and build with Oracle Java set to Java 7 bytecode generation, and test and deploy on IBM Java, to catch any runtime-specific behavior as quickly as possible. These properties have worked on IBM JRE 6 and 7, and Oracle JRE 7 and 8.