Not Waving But …

For a while after moving out of the Big City I felt the only real difference was having a (much) longer commute. However the sights and sounds grow on you (mainly sights, living on a main road the sounds are still pretty metropolitan). This morning we were chatting over a morning coffee we saw three crows mobbing a buzzard. The land to th eback of our house slopes down steeply so the whole event played out at eye level. It was an amazing sight, a really edgy aerial ballet. Eventually the buzzard the buzzard was worn down and headed for the hills but for five to ten minutes we were treated to an entrancing display of aerobatics and a real life drama. Now we didn’t get that in the suburbs!

Well, Here I am on Typo. Still finding my way around and working out the details. I think I am going to have to learn one of the markups soon.

Phil Dawes has an excellent post on problems scaling classic Semantic Web approaches to a moderately sized, messy, real world environment. I have watched him develop his solutions to these problems, the evolution of tag triples and JAM*VAT and it is very impressive. One of the lessons I take away from Phil’s work is that for things to scale in the real world they are necessarily fuzzy. If your system needs everything to work out up-front and will only handle 99.999% of cases then scaling to real world sizes quickly generates far too many problems to cope. As brittle systems (those that require certainty) grow they have to increase their complexity enormously. Building a system that can hold ambiguity without worrying about it until the information is needed means that special cases can be ignored until they have to be dealt with. Which is essentially what Phil has done by leaving the disambiguation to the user of the data rather than the source. What this does mean is that its hard to be certain about the meaning of your data. But that’s just the real world for you.

Thanks go to James Robertson for spotting this… In bytegeist Dermot Hogan argues that “Object Oriented Programming has failed”.

His first example of the massive failure of OO is:
“But let me give you two cases from my own experience. First was the company that was going to build a new OOP banking system. Great idea! Just create a banking class library and use it to build banking applications like cars off a production line; or like shelling peas - or whatever inane simile you want to come up with to disguise the lack of any deep analysis. Or if the truth be known, any analysis at all: this is the world of banking. The problem was (and is, and always will be) that processing dosh does not correspond to an OOP paradigm.”

Now, maybe I’m old fashioned, but my guess is that “the lack of any deep analysis. Or if the truth be known, any analysis at all” probably had something to do with it.

His second example is:
“I was working on fixing a bug in an object oriented Perl system. Yes. Perl can be made object oriented; it isn’t elegant (think of camels dancing) but it does work. I noticed the error low down in the class library and like a good programmer fixed it, got it tested and thought no more about it.” and then after causing trouble for a supposedly unrelated user it hit him: “What I’d done was to modify the behaviour of a base class. And this behaviour had then propagated with effortless ease through the whole damned system. But, with financial systems, this is a no-no. In a typical financial system, all responsible users have to sign off on a change before it goes live. After all this is real money we’re taking about here. Especially if it’s the bank’s own. With this particular system, that sign-off involved users in most of the capitals of Europe!”

Amazing! OO programming techniques now manage impact analysis, regression testing and change management! And I thought they were a way of managing complexity in code.

The sad thing is that there are a lot of developers and development managers out there who really do think that some new technique will eliminate the need for analysis, correct change management process, configuration management and all the other “boring” bits. Well, they haven’t; the “boring” bits are the bits that separate the professionals from the gifted, and not so gifted, amateurs. They can be done, or not, whether you are building with OO, procedural, relational and/or functional technologies. You can do them with lots of, or little, ceremony. They do, however, have to be done.

I had some code accepted into a Ruby project yesterday. Run, don’t walk to SVG::Graph, an SVG graphing package. I am quite pathetically excited about it. Does anyone know of an SVG viewer that runs in Firefox?

I’ve been following the ruby on rails FastCGI vs threads scaling debate and was particularly taken by Cameron Purdy’s comments about Database connections. Which brought me to thinking about the worlds people live in. Cameron, I expect, lives mainly in the high end of “enterprise” (because people only really need his product when they are hitting those walls). Most people don’t, most developers live in the world of one or two databases and a few thousand users. Which leads to two implications:

• most people don’t understand how hard it is to live in that world
• most people don’t have to

The gods did not reveal, from the beginning, all things to us,

But in the course of time through seeking we may learn and know things better.

But as for certain truth, no man has known it,

Nor shall he know it, neither of the gods

Nor yet of all things of which I speak.

For even if by chance he were to utter The final truth, he would himself not know it:

For all is but a woven web of guesses.