The Rescuers Down Under

I just watched this film for about the 5th time (although the first time in many years). It’s the 1990 sequel to the original 1977 classic film The Rescuers. The animation, story, and general quality of the film are quite stunning: it’s little-known, but is comparable to The Lion King, Beauty and the Beast, and other more prominent Disney animated movies. About the only thing that spoils it are the occasionally dodgy voice talents, in particular some of the Aussie accents. It’s a shame they didn’t do what Finding Nemo did 13 years later and bring in native speakers for all the local characters.

If you’re a fan of animation in particular, it’s well worth watching: it’s Disney’s first feature film that entirely used digital composition, and you’d swear there are some parts that use 3D animation (although I don’t think that’s actually the case). The opening sequence in particular is stunning.

WebSphere Message Broker and WebSphere ESB

People are sometimes confused about the differences between WebSphere ESB (built on top of WebSphere Application Server, and using the inbuilt WebSphere Platform Messaging JMS provider) and WebSphere Message Broker (which uses WebSphere MQ as a messaging engine). IBM sometimes describes the latter as ‘Advanced ESB’, but Message Broker is not a superset of the functionality in ESB. There is a good FAQ on the IBM website which clears up some of the confusion.

In general, Message Broker is designed for working primarily with WebSphere MQ, as well as having a larger set of nodes (or mediation primitives, in WebSphere ESB-speak). WebSphere ESB has a richer set of functionality with respect to SOAP and Web Services (Message Broker treats SOAP as plain XML). ESB is also built on SCA, which allows it work more easily with products such as WebSphere Process Server.

ESB and Message Broker can work together: using the MQLink functionality in WebSphere Platform Messaging, ESB can simulate an MQ server and exchange messages with MQ accordingly. They can be complementary and both form part of an SOA solution.

Five Easy Pieces

I’m 50:50 about this film, really. I wanted to like it. It does contain plenty of classic Americana, some nice shots, and some very competent acting from Nicholson and others. The central scene of the film, where Nicholson is trying to order in a diner, is also him at his sarcastic best: work we’ve also seen in later films like As Good As It Gets.

But fundamentally, the film is actually quite boring. The premise has potential: concert pianist turned oil rigger returns to his roots. But the execution is so dry, so tedious, that it really just didn’t hold my interest. The film ends without any conclusion, and is ultimately unsatisfying.

What's in a name? (or: Who exactly are we selling to?)

There’s a tradition in the technology industry of a ‘user’. This, apparently, is the poor sod who’s going to ultimately use whatever you’re creating (software, steering wheels, microwaves, and so on). We’re not sure exactly who he is, but he must exist, right? Many of the more theoretical parts of software engineering use this term, for example: user-centered design, user interfaces, user error (a most horrifically arrogant expression), etc.

As a work for a commercial company, I resolved to give up using this word a few years ago, and call these entities ‘customers’ instead. I figured this would encourage me to be more customer-centric (duh). I’ve been relatively successful at giving up my addiction to ‘user’, and use of ‘customer’ reminds me that a feature / bug / product that isn’t important to one of our customers, although it might be important to a ‘user’, isn’t important to me either. After all, we’re here to make money, right?

But a recent article of Don Norman’s has convinced me that this approach, too, is damaging. Not as harmful as ‘user’, but still wrong. ‘Customer’ works fine for the business. But customers don’t want to be customers. They want to be people, and they want you to care about them and their needs. Thinking of them as people is a reminder that they have human values and failings, and should be recognised in a human way rather than as entities who exchange money for goods and services. Of course you want that exchange, but you don’t want them to feel like that’s the sole purpose of your relationship - otherwise you exclude yet another way for you to differentiate yourself from your competitors (others of which include producing good quality products, cheap products, faster-to-market products, and all the others we know and love).

As such, I plan to try and wean myself off ‘customer’, and onto ‘people’. Please let me know if I lapse.

Would you like some process with that project, sir?

I work in software development, where process is a hotly-debated topic (some think there should be little, some a lot, some think it should be of this type, some of that). Some people can’t even spot a process when it’s staring them in the face, and, to be fair, the definition of processes is not exactly cast in stone.

Scott Berkun understands processes well. He makes an accurate analogy between a good process and the white lines separating lanes on a highway: they restrict the (intended) movement of vehicles, but help everyone to travel faster and more safely. They don’t intrude, they help. Perhaps a slightly more tenuous extension of this analogy to bad processes would be where the lines are constantly shifting about or the lane schemes being re-arranged, in an attempt to improve matters, but actually confusing everyone and slowing them down.

So the important thing to understand is that more process is not necessarily bad, more bad processes are bad (for example, in software products of any significant size, some level of source control is a good thing - but awkward source control will annoy people and encourage them to find ways round it). Over lunch I was listening to some colleagues talking about process, and I came to an important conclusion:

  • People whose sole job is to invent and maintain processes will almost certainly come up with bad ones.

This is because they have no motivation to help, only a motivation to keep their job going, and that means more process (and probably ill-thought-through process). Processes should, with some minor exceptions, be invented with participation from those they affect, as they have a motivation to get it right. If there isn’t a strong enough motivation for them to help come up with a process, they obviously aren’t being bothered enough by the status quo and the process probably isn’t necessary.

subscribe via RSS