My point? Well, apart from the aesthetic and more human readable characteristics of a post that ends “/robbie/why-x-sucks” rather than “/robbie/?p=n”; a decent google rank clearer prefers this. That said, I’ve had a thing about ‘permalinks’ for quite some time. Ever since I wrote my first config utility that had to be reused in multiple applications and environments (using DNS resolution), but especially years ago on an internet web content management system (where I had to justify at a ‘business’ meeting why we were using our own ‘internal’ guid as a primary resolver). At that time there was no little debate about ‘permanent’ or ‘pesistent’ urls or purls, as they were commonly called. Both config utils and links on websites need to relate to resources with specific identities, but it’s the job of URLs to locate those, and URLs change – even if the identity of the resource doesn’t. For example when I upgraded my blog, all my post’s URLs changed. But their permalinks don’t. WordPress uses its own internal locator, so either http://www.wellitworkedlasttime.com/robbie/?p=38 or the new style http://www.wellitworkedlasttime.com/robbie/index.php/2008/wordpress-pretty-permalinks/ is equally valid. And frankly that doesn’t matter – all external cached links on google, twitter  or wherever, will be resolved providing the application is running, and that’s the point. If it’s not, the resource should be unavailable.

The idea that persistent URLs ought to exist somewhere out on ‘the cloud’ is simply wrong. I was about to add this link to purl.org, most known for its use in dublin core metatags perhaps, when I saw this:

“We have reverted back to the old purl server. Any PURLS, USERID, GROUPS, and DOMAINS that were added after 5:50 am edt on 04/07/09 have been lost. We will try to recover them, but we are not sure it is possible at this time.”

An amusing aside (yeah, persistent, my ass!), but my real issue is this from Wikipedia:

“PURLs are an interim measure — while Uniform Resource Names(URNs) are being mainstreamed — to solve the problem of transitory URIs in location-based URI schemes like HTTP. Persistence problems are caused by the practical impossibility of every user having their own domain name, and the inconvenience and money involved in re-registering domain names, that results in WWW authors putting their documents in rather arbitrary locations of questionable persistence (i.e. wherever they can get the WWW space). Existing official PURLs (on Purl.Org) will probably be mapped to a URN namespace at a later date.”

Interim? Impossible? Inconvenient? Expensive? Oh Really? A pretty lame case if ever there was one… In my view the location of a resource is best resolved at the edge, close to the resource itself, by software under the owner’s control. It’s really not that much bother…

there is simply no way anyone would accept that a project manager in those professions could just pitch up and do the job of the professional, never-mind front a professional engagement. but apparently when it comes to IT that’s okay. why? well clearly we architects have yet to establish ourselves a credible profession. in fact, we’re not even close.

there’s another reason though. these days there are many managers in IT who were once (years ago) technologists. that could be a strength, but often isn’t. in the other professions i mentioned, most managers are professionals in their field of business speciality, not ex-technical professionals. i think this leads to a tendency to over-estimate the value such brings to a project and to expect these people can replace, if not actually lead an engagement. given that the state of our profession is so poor; risk averse organisations are more likely to place their trust in what they see to be experienced risk managers who are embedded within the traditional business structures of their organisations.

also, there is a prevalent view that technologists know shit about the business of technology. yet do we really think that GPs know less about the business of medicine than the practice administrators they employ? good management is essential to any engagement, and brings value. no question. but more value than the technical capability necessary to actually deliver an IT project? i don’t think so. in my view, good technologists need to lead technical projects, and good managers need to manage those projects as directed by the technologists in consultation with the client. trouble is large IT companies – and their clients – being chock full of managers-cum-ex-technologists – present themselves on their ability to understand and manage the apparently difficult project or business issues that may be involved, which their IT people apparently don’t get. really? get to fuck. with the right mix of good people, there’s no reason we cant have both.