Find the thread

I've been blogging a lot about messaging lately, which I suppose is to be expected from someone in marketing. In particular, I have been focusing on how messaging can go wrong.

The process I outlined in "SMAC My Pitch Up" went something like this:

• Thought Leaders (spit) come up with a cool new concept
• Thought Leaders discuss the concept amongst themselves, coming up with jargon, abbreviations, and acronyms (oh my!)
• Thought Leaders launch the concept on an unsuspecting world, forgetting to translate from jargon, abbreviations and acronyms
• Followers regurgitate half-understood jargon, abbreviations and acronyms
• Much clarity is lost

Now the cynical take is that the Followers are doing this in an effort to be perceived as Thought Leaders themselves - and there is certainly some of that going on. However, my new corollary to the theory is that many Followers are not interested in the concept at all. They are name-checking the concept to signal to their audience that they are aware of it and gain credibility for other initiatives, not to jump on the bandwagon of the original concept. This isn't the same thing as "cloudwashing", because that is at least about cloud. This is about using the cloud language to justify doing something completely different.

This is how we end up with actual printed books purporting to explain what is happening in the world of mobile and social. By the time the text is finalised it's already obsolete, never mind printed and distributed - but that's not the point. The point is to be seen as someone knowledgeable about up-to-date topics so that other, more traditional recommendations gain some reflected shine from the new concept.

The audience is in on this too. There will always be rubes taken in by a silver-tongued visionary with a high-concept presentation, but a significant part of the audience is signalling - to other audience members and to outsiders who are aware of their presence in that audience - that they too are aware of the new shiny concept.

It's cover - a way of saying "it's not that I don't know what the kids are up to, it's that I have decided to do something different". This is how I explain the difficulties in adoption of new concepts such as cloud computing¹ or DevOps. It's not the operational difficulties - breaking down the silos, interrupting the blamestorms, reconciling all the differing priorities; it's that many of the people talking about those topics are using them as cover for something different.

Images from Morguefile, which I am using as an experiment.

Every time your app steals focus... God kills a kitten.

I have a liking for terrible puns, so I have always had a soft spot for the analyst firm Horses for Sources. Their latest newsletter included a link to a blog post which I'd meant to write up the first time around, but got distracted… ooh! A squirrel!

Ahem. Anyway.

Here's the piece: Time to stop the buzzword balderdash and become meaningful again.

Am I smoking something illegal, or has our industry really started to lose the plot with the amount of buzz terms that – quite frankly – only mean something to the sellers and advisors trying to make their wares sound that little bit savvier than their competitors. And even then, I am not too sure whether many of them even fully understand what they are buzzing about either, more simply regurgitating what their competitors are saying.

They also provide a table of examples, which really doesn't look good for anyone talking about SMAC¹:

I don't think the problem is with people parroting their competitors. Rather, in each company the "thought leaders" come up with terms like DevOps, cloud, or, yes, SMAC, and they mean something specific by them. Over a period of time when they are hashing out their concept, they develop these sorts of verbal shorthand to refer to quite complex structures.

When these deep thinkers are communicating the concept to outsiders, sometimes – often – they forget to provide the extended definition and associated context. Their audience of sales people and other front-liners half-understand the concept, learn the shorthand by heart, and end up in front of customers regurgitating poorly understood messages. The result is basically cargo-cult marketing.

The problem is not that the various visionaries have their own jargon, or even that they talk in acronyms. The problems begin when they come down from the mountain and forget to translate that jargon into common language. The point is not to sound smart to people who don't understand the concept, but to communicate that concept.

A theory that you can't explain to a bartender is probably no damn good.
--Ernest Rutherford

Let me share with you a short e-mail conversation I had earlier today, which perfectly illustrates why users will do anything rather than deal with their IT department, up to and including running their own servers.

Me: Hey IT, what are the video conferencing standards we can support?
IT: Just use Lync - it's the standard!

Me: No, it's somebody else's meeting, and they asked what video conferencing standards we can support.

IT: I don't know anything about this meeting, and anyway it's up to them to send you an invitation you can accept.

Me: Agreed, and they are asking what I can accept, hence my question about which video conferencing standards we can support.

IT: * silence *

As usual, Dilbert is spot-on: I am obviously dealing with Mordac, the Preventer of Information Services.

I'm very late to the story, but I have some thoughts on the topic of URLs going away. Basically, the latest builds of Chrome no longer show the URL at all, following along with a trend which started with Safari on iOS7 hiding everything beyond the site itself by default.

The thing is, civilians have been using the web this way for ages. Few people type URLs or even truly understand how the things work. This resistance is not limited to HTTP, either. One of my pet peeves is the existence of services like Hightail (YouSendIt) or WeTransfer. Neither really does anything different from FTP, at least the way I see them used. If you ask users of these services, though - and I happen to have one handy in my house - they will tell you that FTP is "too complicated", requiring logins and thinking about complex navigation and permissions.

To me, writing out an FTP URL like ftp:// username@hostname/directory/file.ext seems perfectly obvious and natural. When a user receives that URL through email or whatever other mechanism, they can click on it and be taken directly to the file.

The problem is that while I have sent many URLs like that, I can count the number of times I have received a URL formatted that way on the fingers of one hand. URLs seem obvious to me because I'm used to thinking of paths that way, but Muggles don't think that way, and don't want to. WeTransfer hides the scary details, and that's what they want.

My hope is actually that this move leads to the return of separate address and search fields, with the address field hidden by default. That way I could turn the address field back on, and finally be able to connect to hostname on my local LAN instead of being sent to a Google search for "hostname".

I want to share a couple of stories, both via the Quartz Daily Brief email newsletter.

Car headlamps are good for cannabis. Gangs are nicking LED bulbs from luxury vehicles to use as growing lamps.

What to do about a problem like that? Quick fix: legalise weed, save the LED headlamps!

Not so fast:

Legal weed leads to cheaper heroin.

Mexican pot farmers stung by cheap US competition a
re now producing opium instead
.

This sort of thing happens all the time in IT too. There's a problem, a quick fix is hacked together, and now we have two problems: the original problem that didn't quite get fixed, and the new problem of maintaining the fix.

If you have an issue, and your first reaction is "I'll just write a quick script to fix that", step away from the keyboard and think again. That quick script takes time to write, and then more time to rewrite properly once you figure out all the edge cases and conflicts. Then it takes even more time to maintain and update over time.

There's a big opportunity cost in doing all that work. Think of what you could (or should) be doing instead. Prohibition pushed good scientists out of oenology, in effect jumpstarting food technology. Everything we do has consequences, and most of those are unforeseen.

Think before you script.

A piece I wrote on Heartbleed was published in Cloud Computing Intelligence magazine:
Once you’ve dealt with Heartbleed, how do you prevent it recurring?.

Summary and lead-in:

You've got rid of Heartbleed, and you're relaxing with a soothing cup of something strong, but how do you know that it's gone for good? Dominic Wellington looks at creating a containment policy for Heartbleed and for any subsequent nasty bug that will stop them from coming back to plague you again.

Feedback welcome!

Automation of single tasks with point solutions is equivalent to premature local optimisation of code.

The worst part is, in both cases you may end up trapping yourself on a local optimum. It's hard to abandon these maxima and cross the valley to the higher peaks, no matter how attractive they look.

It doesn't get easier over time, though. Start thinking holistically now. Talk to your peers in different teams. Better yet, talk to your users. They'll tell you what they need.

One of the things that make it most frustrating to use the web from an iPhone is form inputs. Reading the content is generally doable - and if not, there's always Instapaper. But form inputs are always a pain. Partly this is because they're over-styled, so you get stuck with fields that are either tiny or huge. Sure, testing that sort of stuff gets annoying fast. What about the stuff that is easy to do right, though?

One of the things the iPhone does is to show the user a different keyboard depending on the context. If the entry point is in an email address, the keyboard shows characters that are used in email addresses - the @ mark, dashes and underscores, and so on - instead of the space. If it's a phone number, you get a numeric keypad. This makes life much easier.

All of this is driven by the type of the HTML input element. Set it to email, tel or whatever, and let iOS do its thing. But no, nobody bothers to set their input element type, so iPhone users are switching back and forth, hunting and pecking, and all the time hating web developers so very, very much.

And that's just one tip for this useful list of
8 HTML Elements You’re Not Using (and Should Be). Go, and do ye likewise.

The datacenter of the future will be staffed by a man and a dog.
The man is there to feed the dog.

The dog is there to bite the man if he tries to touch anything!

Vick Vaishnavi, back in the day