Overheard last night at XtC:
“I work for Dresdner.”
“Ah, they used to be a cool international investment bank.”
“What are we now then?”
“An international investment bank.”
“Why aren’t we cool any more?”
“Because you lost JP.”
I was having a discussion last night about the value of learning new programming languages. I said I still felt I ought to learn Lisp, even if I was never likely to use it in anger, because it would hopefully give me a new way of thinking about problems which would be transferrable to other languages (especially ones like Ruby). Alkesh (come on, get a blog so I can link to it!) felt that Lisp was a dead language, and would be no more useful than learning Fortran or COBOL.
Then this morning I tried the Which Programming Lanuguage Are You? (via Steve Freeman).
Fate?
Most large organisations have been using SOA for years, and they’ve been doing it despite their IT strategy, not because of it. No, not Service-Oriented Architecture, but Spreadsheet-Oriented Architecture.
Simon Baker has posted a response to John Scumniotales’s post on Team Leadership and Self Organization, and I have to say I’m with Simon.
AS I mentioned at the end of this post, I’ve been convinced by Dan North’s case for using the “given when then” pattern for specifying scenarios during behaviour- or test-driven development, and while I wait for JBehave to be released, I’ve been playing around trying to come up with a way of using the pattern to clarify intent in (Java) unit/acceptance tests.
A slightly cynical post from Kevin Barnes today – bizarrely entitled Agile processes, are they killing our children? – contains the following line:
Managers like the waterfall model for the same reasons that tourists like real waterfalls, they are simple and powerful and beautiful to look at. They are much less fun when you go down one.
I didn’t think he’d be able to top that, until I read down a little and laughed out loud:
The one group that always had mixed feelings about the waterfall model was consultants. Consultants can’t afford to show up, work for months at a time and produce no real results (unless they’re Accenture).
It’s quite common these days for organisations to allow external access to their intranets using an SSL VPN, but it can be a bit of a pain if you’re trying to follow a ‘normal’ intranet hyperlink (eg from an e-mail) – you have to paste the URL into a box on the VPN homepage and have it converted.
To make it easier I’ve created a bookmarklet to do the conversion. It may not work for all sites, as I’m only constructing the new URI based on a simple inspection of a couple of pages.
There’s an excellent article about the Toyota process on fastcompany.com. Most of the behaviours described are also desirable or necessary in teams or organisations trying to be[come] agile, but the key point is in the conclusion:
Ever since I started work, people have had big blue (or more recently black and red) books that they wrote stuff in. I’ve always called them lab books, but that seems to cause amusement to some people, presumably because I don’t work in a lab.
Some of the things that were written were notes from meetings, to do lists, or rough design notes. The most important ones though, the ones that you kept referring back to (if you could find them), were the little snippets of secret knowledge that everyone accumulates as they learn the intricacies of their particular job, whether it’s useful unix commands or instructions for using a particular build system.
Agile teams tend to favour whiteboards for instant collaboration when discussing design etc, but if you’re working in a pair you might not always want to keep walking over to one on the wall. The answer? A4 whiteboards!
They only cost a couple of pounds each (including a pen), and at the risk of attracting ‘XP isn’t for grown-ups’ comments, the best place to buy these seems to be primary school suppliers – for example Class Ideas or EasyTeach. At that price, you may as well have two or three each.
[tags]agile, tools[/tags]