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.

This morning I was writing a test plan document. It contained lots of technical nitty-gritty and detail, but a lot of it was the same stuff repeated over and over again. It was very tedious to write (and hence undoubtedly error-prone), but necessary. I kept thinking how useful it would be if I could automate the process. I knew it was just a little too complex, and contained a few too many exceptions, though, that writing a program to do it would be more trouble than it would be worth.

As an experiment in being a cheapskate (I normally spend too much), I travelled on a Megabus from Winchester to London at the weekend. To pass the time, I attempted to assess the usability of the light situated outside the toilet (I’d left all my good CDs at home). My train of thought was as follows:

After seeing the light turn on when someone went inside, I assumed I was correct in my initial guess - it was to indicate it was occupied. So far, so good - although things would have been less certain if you hadn’t been sitting next to it and seen it do this before. However, the light stayed on for 3 minutes after someone left the toilet. After seeing this consistently happen twice, I figured it must be going through some cleaning cycle - thus the light really meant ‘do not enter’ rather than ‘occupied’. I was just congratulating myself on figuring out this rather straightforward pattern when a further complication arose - as we approached London, and the roads got bumpier (or so I theorized), the light seemed to switch on and off fairly randomly, and this time I just couldn’t correlate it with anything meaningful. Perhaps just a faulty connection in a switch somewhere, but it made me question my previous two conclusions to the extent that as I got off the bus, I realized that I hadn’t really learnt anything at all. Perhaps the light had nothing to do with the toilet, apart from being located nearby.

It’s interesting, working in a modern knowledge economy (I’m not yet sure whether I like that term), how much happens behind the scenes that you’re not aware of. This is the wonder of economic specialisation and trade.

I was reminded of this today on a small level, because one of the buildings here at Hursley has broken air-con (the south of England is currently experiencing a mini-heatwave and I think it’s just become too much for our system). I thought of the time I toured the tunnels and back-rooms of our office buildings here, and became aware of all that happened - the huge heaters and air-con units, the electricity and water supply, and all the things we take for granted. The engineer showing us round (who was a contractor) was clearly a specialist in all of this, and took great pride in his domain. I knew next to nothing about what he was showing us, and became aware how dependent we were on him and his colleagues.

Corriere della Sera said of Dog Days:

‘Those who have seen this film will never forget it, whether they loved it or hated it’

Well, I certainly didn’t like it, but I also think it is ultimately forgettable. The various stories within the film (whose only common thread is that they happen during a heatwave in Vienna) are vague, directionless, and mostly uninteresting. The characters are tedious. The hitch-hiker who seems to be suffering from some form of autism is by far the most interesting character, but even her scenes become repetitive after not too long.

Color of Night is an odd film. It starts off as a dreadful drama. The plot, though quirky, is jumpy and inconsistent - although not challenging. Bruce Willis plays his typical smartass role, totally unsuited to the psychiatrist he is supposed to be. He seems out of place in this movie. We know he can manage atypical roles (Death Becomes Her) but he doesn’t manage them here. Scott Bakula plays another psychologist, a friend of Willis - he portrays a relatively believeable character but gets killed off too quickly. The cop assigned to investigate is an even more camp version of Luis Guzmán. His sympathy for Willis is ridicously non-existent. The therapy group that Willis adopts when Bakula dies is full of parodies of nutcases, not nutcases themselves.

This film is either going to be amazing (I’m currently guessing Mulholland Drive meets Airplane meets Gremlins) or truly awful. Why haven’t I heard of it before?

Advantages of using synchronous behaviour in an ESB (such as SOAP over HTTP):

• You want your clients to be simple to write - with asynchronous behaviour, when a reply comes back to a client, it needs to know how to correlate that with the request it sent out (this is one reason JMS has the concept of message and correlation IDs). This probably requires it to keep some state hanging around. This isn’t necessary with synchronous behaviour, as the client thread blocks waiting for the reply.

  More ...

Edward Tufte’s excellent essay ‘The Cognitive Value of Powerpoint’ contains an excerpt from Lou Gerstner’s autobiography, an anecdote from when he first joined IBM in the 1990s, when the typical method of making presentations was to use PowerPoint (or similar software of the period), often producing results with a low signal/noise ratio. Lou was less familiar with this, and after enduring a short part of a presentation from one of his senior executives using this method, Lou asked him if we could ‘just talk about your business’. This was famous within and without IBM at the time. Nevertheless, it seems to have been rapidly forgotten. IBM presentations still often have a low signal/noise ratio, with slide ‘decks’ used as a general method of information exchange (sent round in emails, used as substitutes for essays and documents). Tufte explains in detail why this isn’t an optimum method of communication.

SOA (Services-Oriented Architecture) is a very general idea; the notion of defining business and computing logic as interconnecting services, typically in a distributed computing environment, where some services depend on (call upon) others. SCA (Service Component Architecture) defines some terminology and standards for this, using the concept of SCA modules - you can think of each module as being a black-box service. SCA modules can import services from other SCA modules (which have corresponding exports, defining the services they provide). They can also expose (export), and call upon (import) services via other protocols.