Mine's Better Than Your's

I’m more than a little amused at the current Rails versus Hibernate versus EJB3 versus whataver, debate that is raging at the moment. It’s not that I don’t mind a bit of argy-bargy. I think this kind of discussion is very healthy. I am a geek after all. I just find it all a little, well, tiresome sometimes. I probably wouldn’t mind so much if the arguments didn’t center around what is supposedly “best”.

Mac users would argue that OS X is better than windows, though windows sales surely outstrip OS X sales by a few orders of magnitude I’m sure. BMW drivers would argue that even the bottom of the range BMW is better than say, a top of the range Toyota, though again, I’m sure that’s not reflected in actual sales numbers. And then there is of course the oft-cited BetaMax versus VHS, IBM’s MCA versus Intel’s ISA. Motorcycles with Mick Doohan’s name on them sell for much more than those without. The guy in the motorcyle shop will thus try and convince me they’re better because they are “popular”. Just because a piece of software (or anything for that matter) is popular, doesn’t make it good. That is of course unless your definition of good is popularity.

Natural selection - and that’s how I see this - doesn’t necessarily choose the “best”, it merely chooses the fittest and, unfortunately, the fittest may well come down to things like, documentation, sales & marketing, how many other people seem to be using it and, gasp, how many books there are on the subject.

Most of the time I hear the argument for using Struts (for lack of a better example), it’s more about the fact that most people “know” struts and very little about whether it is good or not. In fact, my experience is that, while it is pretty easy to get going using Struts, it’s also very easy to shoot yourself in the foot. To the point that I’ve rarely, if ever, seen it used well. That’s not to say that it can’t be used well, just that it usually isn’t.

There are far too many factors that affect the software development process that go waaaaaaay beyond the technology and tools you use. I’ll put my nuts on the line and say that most if not all project failures have little if anything to do with the technology (except as a consequence) and are more to do with the the failings of the people, the skills and the communication.

No, what I want to see is some empirical evidence that says, hey, we built a large scale app in whatever tool it is and look it performs well, the customer is happy, our defect rates are very low, we delivered on time, on budget, and the quality of our code is excellent. And I want you to prove to me that it worked BECAUSE of the technology and not JUST because it had some really good developers on it. then, perhaps then, I’ll go recommending to a customer that they shell out a gazillion dollars to fund my latest passing interest in a tool I read about on the internet and became interested in because I was so bored with whatever tool I used on my last project.

And it’s not even that I don’t like the look of all these tools. It’s not that I’m not interested. In fact I am bored with the stuff that I write most of the time. I’ve been hangin gout for ages to find a project where someone will give me money to play with Ruby. But that’s not the problem I’m being paid to solve nor likely even the problem that I have - the two may well be different!

So rather than tell me why it’s so good, instead explain to me Why I Should Care™. (Because there are 5 books on it is not a valid answer.) Tell me how it solves a problem that I do have rather than how I can do the same things I’m already doing, differently. As far as I can tell, a lot of it comes down to personal preference and pissing competitions.