SteveJ-restore-test

Alan Kay invented Object Oriented Programming around 40 years ago with Smalltalk. Kay not only has a lot to say, his accomplishments lend him credibility. In 2003 he said: "our field is a field that's the next great 500-year idea after the printing press" The ACM awarded him its highest honour, The Turing Award , in 2003. The short Citation: For pioneering many of the ideas at the root of contemporary object-oriented programming languages, leading the team that developed Smalltalk, and for fundamental contributions to personal computing. Video of his 60min talk on the ACM site , and elsewhere, a transcript . The slides & demo used are not available. This 1982 talk for "Creative Think" brought this reporter reaction (the link is worth reading for the list of line-liners alone): Alan's speech was revelatory and was perhaps the most inspiring talk that I ever attended. This is my current favourite quote of Alan Kay's from Wikiquote: "Point of view...

This post by Dana Blankenhorn on ZDnet is the best answer I've seen to the question "Why Open Source?". He says 'plumbing', I'd say '(Unix|Open Source) is the Universal Glue'. And the on-going Open Source Business Model is "support" for those that need/want 'certainty'. Which if you are the CIO (read: 'my arse is on the line') for somewhere with a high dependence on I.T., is only Good Governance (or "common sense"). You can't make key staff stay, nor mandate they never get sick or burn-out and "go sit on a beach" - and after '9/11', all Business Continuity plans have to account for covering people as well as systems and networks. That's it - Business I.T. is all about the Data (or "all about XXX, stupid" to be Clintonesque). Open Source tools are usually about manipulating data or providing services - like Apache, e-mail, DNS, firewalls and IDS, ... Open Source is here to stay: u...

A friend came back from a ITIL Practitioners course with an interesting story: The course was mostly about the complexities of handling Commercial Licenses, no two of which are the same. The course provider made the not unexpected statement about Open Source: "Don't use it because you have nobody to sue". And they went onto ask "Why use OSS?" His response was: "Because it's best of breed, especially rock-solid utilities & tools". And they continued to not listen... This note is NOT about that particular mindset [Risk Avoidance, not Risk Management]. I'd like to give him, and other technical people like him, a "slam dunk" one-liner response to each of these questions: Why OSS - because it's best of breed! Why use a bug-ridden, poor functioning piece of commercial software when the best there is is rock-solid, secure & Free and Open? Not only do you remove the need to sue *anybody*, you get the best tool for the job and k...

This started as a conversation on an Open Source list - on how to respond to people that assert: "We can't use Open Source because there's Nobody to Sue". This is a response I received: The "Who can we sue" issue should be questioned. (i) Can the 'propriatory' software company be successfully challenged? Ask them how many people have successfully won a court case against Microsoft for example? (ii) To sue someone you need to allocate resources to the 'sueing' budget. Ask them that if they plan to sue people then have they budgeted for the possibility? or do they expect their insurance premiums to cover that? Wouldn't the insurance companies be concerned about the 'who to sue' bit and not the company? (iii) You can have software companies who write non open source software who have no money. Sure you could sue them, but you end up losing money and if you send that company broke who is going to fix or maintain the non open code th...

My last post took me most of a day to produce. Not a great words/minute rate. I'd expected to spend no more than an hour - it's work that I first did around 2000, so I'm familiar with it. A friend jibed that "You should've used your I.T. project management methodology". I do have stong views on managing I.T. projects, especially large one, and they are backed up by the solid research data from Standish Group. They do apply to exactly this task of writing. Unfortunately they offer no useful guidance. All new programs are research projects If you haven't got working code, you don't know how long it can take. If it's a complex task, then beforehand you cannot know where the 'beartraps' are. At any point in a project, you can only see in detail a couple of weeks ahead. 'Scale' is everthing [Alan Kay's argument]. Don't take on any project more than 30% larger than one you've completed successfully. Everyone is an efficient,...