If you’re trying to implement it because you’ve heard of it and it seems to be The Thing, then that plume of smoke on the horizon is the boat you missed.

I would argue it’s never about the killer app or killer hardware.

It’s about meeting the killer requirement.

PS. I did say “po”

The first one says, “I don’t know.”

The second one also says, “I don’t know.”

The third one thinks for a moment and says, “Yes!”

Hat tip to Language Log for that one…

(This reminds me of the much shorter joke: One behaviourist walks up to another at a party and says, “You’re doing fine. How am I?”)

I’ll get my coat.

I’ve never really understood the level of unhappiness that change can generate within IT departments, which are usually about driving through as much change as possible to the rest of the business. Now I understand graduate coders getting shirty about requirements changing, and I’ve put enough change management in place to understand why you do it. But once you hit a certain level of experience and professionalism, whether or not it’s Gladwell’s 10,000 hours, surely you ought to stop being surprised by change and start being prepared for it?

Tons of practical consequences from that. In a SOA, from a technical viewpoint, it means get your contracts right, understand forward and backward compatibility, understand how your users are binding to your services and make sure you give yourself some wiggle room, because you’ll need it. In a larger context it extends to your supplier relationships, the developers your recruit or source… and to pretty much everything you do.

Are vendors just moving industry IT forward from one steady-state to the next? I can’t help but think a lot of people believe that This Time Is Different….

Then there are your business’s order-of-magnitude “constants” – transactions per peak 15m, online sales per day, percentage online fulfilment, and so on. Those are the tricky ones — they’re not constants, because your business people are busy trying to change them (while you’re trying to do capacity management), but they crop up in lots of your rules of thumb. How often should you revisit them? In an ideal world, wouldn’t you like them on a dashboard on your phone?

So my thought for the day is, keep your eyes open and don’t let the sea of three-letter acronyms and high falutin’ architectures distract you too much from the fact that most of your code is going to run in a really specialist execution environment — reality. To heavily paraphrase Mr. Feynmann, you can’t fool that with bullet points. Keep testing your assertions against reality.

It was a great experience to spend three days doing nothing but listening to incredibly smart people talk about the things they’re passionate about in software. In fact, it was positively luxurious, and it really fired Stewart and I up to start getting a fresh current of ideas into our everyday work. I left wanting to learn Erlang immediately (Joe’s talk was a particular treat), to have my systems continuously available, to base everything on a web architecture, to do JIT architecture and, oh, everything all at once, even if the enthusiasms were mutually incompatible (write it all in Scala! AND Erlang! and Ruby!).

Of course, a set of unstructured enthusiasms does not a plan of action or a coherent system make. But all those sessions felt like a set of design patterns for approaches, rather than for software problems – and that’s a useful resource for anyone in any business.

I'm speaking at QCon London

I have a sneaking feeling that being surrounded by all those clever people is going to make me feel woefully simple….

Of course, if you hover over a link in Mail.app, you get a little tooltip that tells you what the target is. Maybe it takes a fraction of a second too long to pop up — I know I get horribly irritated by this in Eclipse, which has perfectly sensible tooltip timing on WinXP, but needs a written invitation on Leopard — but I perceive it as taking something like the standard time for tooltips on OS X, rather than the week I wait for SWT. And generally Apple have good form (at least in my opinion) when it comes to HCI and timing…

All of which has deprived you of the debatable benefit of my pithy wit this time round. There are at least three distinct conclusions I could draw from the whole sorry affair:

• I am an unobservant muppet
• Generally, tooltips on Leopard take just a little too long
• Notes’ UI is so poisonously bad that obvious things are obscure after using it

I tend toward the last with a little of the second; natural reserve prevents me from prejudicing your views in regard of the first.