Tag Archives: Computing

Cloud Without Compromise

I couple of years ago I did a conference talk called “On Cloud Nine: How to be happy migrating your in-memory computing platform to the cloud.” I wish I’d had “Cloud Without Compromise” back then. It covers much of the same ground but, as you’d expect in a book rather than a forty minute conference talk, in much greater depth. More importantly, it puts some concepts into context much more clearly that I did, either by explaining it better or by giving it a good name.

One of the main takeaways of the book, something that is mentioned throughout, is the mantra “Cloud is a capability rather than a destination.” In my talk I hint strongly at that but never made it explicit. I always felt that “the cloud is just somebody else’s computer” didn’t fully encapsulate the magnitude of change but wasn’t able to articulate it concisely. Well, here’s the line to use.

This book took a long time to read. Not because it’s badly written or exceptionally long but because every few paragraphs I had had to stop and think about the implications, how the subject applied to my recent work or research a new tool that I had not come across previously.

There have not been many technical books I’ve read recently that have had this impact. Naturally not everything was new to me, but even then rephrasing a concept or putting it into context can be immensely useful.

It is also very approachable. There’s a nice appendix on some of the more technical aspects, there are some nice anecdotes and even a little humour.

“You’re the most unromantic person I know.”

If there’s a criticism, it’s that some parts read as an advertisement for IBM and RedHat. The last chapter in particular, which is about automation, could be a White Paper for Ansible. Sure, the focus of the book is on hybrid cloud, where the other big vendors are pushing their own agenda, but the OpenShift advocacy would be less signifiant were it not for the fact that a couple of the authors work for IBM. On the one hand you have to write what you know. On the other, shilling your employers products in what’s supposed to be a vendor neutral book sits awkwardly.

For what it’s worth, the advice does not appear to be incorrect but I wish there had been more discussion about competing products or they’d stayed clear of talking specifics at all.

Overall, though, “Cloud Without Compromise” comes highly recommended.

The Computers That Made Britain

I’m still fascinated by the computers of the eighties. Without well known standards, every machine was different, not only from those of other manufacturers but also older machines from the same company. As as user it was terrible. Back the wrong horse and you’d be stuck with a working computer with no software and no one else to share your disappointment with.

But looking back, there’s a huge diversity of ideas all leaping onto the market in just a few years. Naturally, some of those ideas were terrible. Many machines were rushed and buggy, precisely because there was so much competition. Going on sale at the right time could make or break a machine.

Tim Danton’s “The Computers That Made Britain” is the story of a few of those machines.

He covers all the obvious ones, like the Spectrum and the BBC Micro, and others that I’ve not seen the stories of before, like the PCW8256.

While it’s called “The Computers That Made Britain” rather than “Computers that were made in Britain,” I would argue with some entries. The Apple II is certainly an important computer but, as noted in the book, they didn’t sell well in the UK. Our school literally had one, and I think that’s the only one I’ve ever seen “in the wild.” Sales obviously isn’t the only criterion, but the presence of these machines presumably pushed out the New Brain and the Cambridge Z88 (among others). Since this book is about the computers than made Britain, I would have liked to see more about them and less about the already well documented American machines like the Apples and IBMs.

The chapters are largely standalone, meaning you don’t need to read them in order. I read about the machines I’ve owned first, before completing a second pass on the remaining ones. They’re invariably well researched, including interviews with the protagonists. Some machines get more love than others, though. Talking about the Spectrum, it finishes with a detailed look at all the subsequent machines, right up to the Spectrum Next, though curiously missing the SAM Coupe. But the Archimedes gets nothing, even though there was a range of machines. Did they run out of time or was there a page count?

But those are minor complaints for an otherwise well put together book. Recommended.

It’s published by the company that makes Raspberry Pis, which you could argue is the spiritual successor to the Sinclair and Acorn machine. You can download the book for free, but you should buy it! The above link is for Amazon, but if you’re near Cambridge you should pop into the Raspberry Pi store and pick up your copy there instead.

If this is your kind of book, I would also recommend “Digital Retro” and “Home Computers: 100 Icons that defined a digital generation,” both of which are more photography books than stories.

Meetings

After university, when I first started working, I jealously noticed people leaving their desks and attending meetings. I was left sitting at my desk, bashing out code. What was going on? What exciting things were being discussed without me? Sometimes they’d come back from the meeting and ask a random question. It was all very mysterious.

A while later I started getting invited to these meetings. I found what was being discussed. I discovered the mystery.

I’ve spent the rest of my career trying to avoid them.

Of course, meetings are not inherently bad. Sharing information, collaborating, making decisions are all vital functions of a company and you need meetings to do that. So why are they often so bad? And why do I spend so much time trying to avoid them?

Meetings are a cultural artefact. Good and bad etiquette isn’t evenly distributed. The companies with the worst meetings are also, ironically, the ones with the most.

What makes a good meeting? There are lots of articles on the web about this, so I don’t want to belabour the point, but, actually, I think it’s quite simple:

  • A defined function
  • The right people
  • The right duration

Missing any one of those means that the meeting is going to be a waste for at least some of those attending.

By “a defined function,” yes, I mean an agenda. It doesn’t necessarily have to be a full and formal written agenda, but all attendees should know the point of the meeting. If they don’t, maybe you do need to write it down. I encourage people to decline meetings with an unclear objective1.

The “right people” to invite to a meeting is often driven by the org chart, but this is completely the wrong metric. You need the fewest people that can meet the objective of the meeting. Don’t include someone just because they’re “important.” Don’t exclude someone because they’re too junior. Include everyone needed to share information or make a decision, or whatever the goal. But no more than that.

One thing that infuriates me is where people in a meeting have no “function.”2 Everyone should have a clearly defined role. If they don’t, they shouldn’t be there.

What about duration? I see two sides to it. First, work expands to fill the time available. Don’t do that. If you set aside an hour for a meeting but it actually only takes ten minutes, quit while you’re ahead. In fact, for people that tend to take a while to get to the point, I’ll deliberately book short meetings.

Conversely, if you’ve spent an hour going around in circles without making a real decision, maybe it’s time to call it a day. Your conclusion should be the information you need to actually make a decision, the people who are going to obtain it and, hopefully, when the next meeting will be.

Talking of “an hour,” that’s my benchmark for maximum meeting length. Anything significantly longer than that suggests to me that there isn’t sufficient focus or a tight enough agenda. And, perhaps more importantly, people are just not going to focus that whole time. They’re going to drift off into a dream world or check their phone. Why have them in the room physically if they’re not present mentally?

It all sounds so simple when you put it like that and yet we’re all guilty of Doing It Wrong. If there’s one thing to take away, it’s that meetings should be deliberate, just like any other corporate artefact.


  1. There are exceptions. For example, I wouldn’t decline a meeting with a client but I would seek clarification. ↩︎
  2. When Dilbert was good, there was a character called the Meeting Moth. I think we’ve all worked with people like that. ↩︎

Mismatched

Here’s something I’ve seen a few times recently: a startup issues a patch for a critical issue seen by one of their large customers. The “enterprise,” however, takes a week to install and test it. Clearly, the startup concludes, if it takes a week to try a patch it can’t be that urgent or the staff are dumb, or, quite likely, both.

Separately, we all know that a big difference between a startup and an enterprise is process. So why do people suddenly get angry and start to lack empathy when that difference is exposed?

What we saw in the first paragraph is normal in big companies where you can’t just promote changes into UAT, much less production. It doesn’t matter how loudly you shout at their operations team, it’s not going to make any difference. Maybe the process requires writing test logs and rollback plans. Perhaps it has to be deployed and run in the pre-production environment first. It likely needs sign-off by the QA and security teams. With the best will in the world, this just can’t be done in a few hours, no matter how critical the issue is. Who is to say that the patch isn’t worse than the problem it’s trying to fix?

The difference is frustrating, but don’t mistake tedious process with a lack of urgency or incompetence. Circumventing process can take longer than following it and your client probably knows that. If nothing else, these people might lose their jobs by not following the right process!

Work with it, understand their constraints. This isn’t the time to lose that empathy. It would help if you also had humility and understanding. You know your product but they understand their systems, including how your software interfaces with the other applications they have running in their data centre.

And yes, working with their process is more complex and time-consuming. This is why we charge enterprises more for, ostensibly, the same features.

Innovation department

When I see a company that has an “innovation team” or a “chief innovation officer” I immediately understand that it’s not the kind of company I want to work for.

Innovation isn’t found in a particular team, person or department. It’s your culture.

If you need a special team outside the normal management structure to innovate, what does that say?

iTunes Match — addendum

Since I wrote about iTunes Match nearly eighteen months ago I thought it was worth revisiting and seeing how things have changed in that time.

Oddly, the short answer is “not very much.”

The problems that I identified last year are still very much present. Indeed there are some new examples. This is my favourite: when listening to “Man Machine” by Kraftwerk, iTunes Match seems to have decided that track four, which should be “The Model,” is really “Wouldn’t it be nice” by the Beach Boys. I don’t even own a copy of “Wouldn’t it be nice.”

The biggest changes in those eighteen months have been on the client side. iTunes 11 (the lipstick on pig release), as far as I can tell, didn’t change very much. iOS 6 wasn’t nearly as fortunate. The point zero release removed the ability to delete individual tracks. Not exactly progress. (It’s back again in 6.1.)

Apple likes to talk about its magical products that Just Work. iTunes Match tries to be more magical than most but clearly missed a few visits from the faeries.

One bit of magic that I thought was supposed to happen was that when getting low on disk space, iTunes Match would delete less played tracks. In fact, what I think happens is that it removes older, cached tracks.

The distinction here is between cached and downloaded. If you press the download (cloud) icon it isn’t automatically removed; if you didn’t it is.

But how do you tell? Well, that’s the other major client flaw. There’s no easy way to see which tracks have been downloaded without opening each album, one by one. I have six hundred albums which makes this an exceedingly tedious task.

My guess is that you’re supposed to use it by just pressing the Play button and have iOS manage the space for you. But this would mean you live in a utopian universe where you have a data signal every time you want to play some music. That does not resemble my life.

What I want it to be able to download tracks that I think I’ll want to listen to and then allow playing from the cloud. When low on space it should remove tracks that have not been played recently regardless of how they got there.

So eighteen months on I find that many of the same problems remain and I’ve found some new ones, yet I still paid for another years subscription without much though. Why? Well, it’s still very useful. I like being able to play music using my Apple TV. I like being able to access any of my music when I have wifi or 3G. I just wish Apple would spend a little time and make it less like a 1.0 release1.

  1. You could argue that they added iTunes Radio, but that only comes with iOS 7 — nearly two years after iTunes Match came out — which isn’t out yet and even then that will only work in the US to start with. []