Being careful to distinguish between metaphor and simile, it came to me today that software projects are like turkeys.

You can’t achieve the same effect when roasting a turkey by doubling the temperatuire and halving the cooking time. Similarly a project cannot have the number of people doubled and the duration halved and get the same result. The rate of knowledge crunching is not increased by adding more people.

In general, my experience of programming is that the real benefit of automated refactoring tools is most fully realised when working in teams. When programming on a personal project (or as a single pair), there is less conceptual drift, and its easier to make design changes without trampling on other people. Its also okay for design changes to take a while without risk of confusion.

This may be why the Ruby/Rails community don’t (at present) find the lack of a strong IDE for ruby to be a big impediment. I think that when larger teams (6+ devs) starting developing significant projects in Ruby, the lack of tool support will begin to be felt, particularly by those who have become used to the refactoring style of working, where its okay to defer decisions like what to call methods, parameters, classes etc.

You know two developers having an argument about technology are suffering from a certain lack of common ground when one says, ‘But it’s XML!’, to which the riposte is, ‘But it’s XML!’.

This is one of those products that seems obvious in retrospect. Tesla Motors, a silicon valley startup, has developed an electric car with not just real-world performance, but real world Sportscar performance. Capable of 0-60 in 4 seconds, a top speed of 130 mph, and a range of 250 mph, Porsche should be scared. And it runs on laptop batteries. That’s right, this thing’s electric. Quite literally.

Designed with silicon valley smarts, styled and built by Lotus. Not only is it fast and environmentally friendly, it looks gorgeous! The future of cars might have just arrived. And I want one. Hurry up and bring it to the UK!

Buildix has been released. Some of the build experts from ThoughtWorks have put together a linux distro with a bunch of our favourite open-source tools for source code management, issue tracking and continuous integration, all plumbed together with some handy scripts. Its available either as a Knoppix live-cd or a VMWare image, so getting up and running should be a breeze. I’ve been waiting for this for a while. The barrier to getting an agile project up and running has just got lower. Check it out.

As someone who tends towards overdoing it, I have found the Cool Running couch-to-5k plan exceedingly helpful and would recommend it to anyone who’s feeling the urge to get off the settee and hit the tarmac. My usual running sprints (hah) tend to end up with me slogging to hit an impossible target followed by nearly a week of silly walks as my muscles unstiffen. So far I’ve had no post-training side effects, and every session leaves me hankering to get out there and do the next one. This is an addiction I could get used to.

Seems a bit messed up when Scoble leaving Microsoft rates a mention in the UK breakfast news headlines, right next to a slot describing the concern about the state of the US economy. ‘One of the world’s most famous bloggers’? For a definition of ‘world’ that only includes software geeks perhaps.

Those who do not pay attention to politics shall be at the mercy of those who do.

The fallout from having to cancel all my credit cards continues. Huge thanks to my hosting provider, JohnCompanies for not deleting my account after an unfortunate confluence of events involving them not being able to bill me for 2 months, and me not checking the email account that they were trying to contact me on. It might take a while for DNS to propagate, but the site is more or less back.

What I really really want…

I’d love to see EAR files made more useful by allowing them to be run from the command line. ‘java -ear MyApplication.ear -cp library1.ear;library2.ear’. Even more useful would be to make the default classloader understand EAR files as complete units of deployment, and allow different versions of the same jars to exist within different ear files. Borrowing from J2EE, it should be possible to have a classloader to look inside the local EAR when trying to load a class, and then look in the rest of the classpath. So if MyApplication.ear contains version 1.0.4 of commons-logging.jar and library1.ear contains version 1.0.2, any classes within MyApplication.ear would see 1.0.4, and those in library1.ear would see 1.0.2.

This does mean that if MyApplication was interacting with a class in library1, and tried to reference an instance of a class that was defined in both ear files, a ClassCastException would result, but in my opinion that is not particularly a limitation. If I need to use an API from a library, I should not be concerned with the libraries (or versions thereof) that it chooses to use internally. The present jar based paradigm simply does not allow me that encapsulation.