Mine's Better Than Your's
Listen to this article
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.
Comments
Projects have definitely failed due to technology. Sometimes projects are overly ambitious, and try to push technology further than it can go right now. Other times, a niche technology is used successfully, but it becomes impossible to get people to maintain it later. Arguably these are second-order effects, but it's still a factor.
Popularity has its good and bad points. You can point at anything popular in IT and show hundreds of screwups with it: the majority of IT projects _are_ screwups, and naturally the popular technologies get more than their fair share. The niche technologies, OTH, tend to be attractive to the better quality people, so they have less screwups. As soon as it becomes mainstream, however, the screwup ratio starts climbing.
What I get sick of are the "apples and oranges" comparisions. The Ta-Da vs Bla-Bla comparison was like that: comparing an OO-style to a mostly procedural style and declaring the OO-style to be "the winner".
Posted by: Robert Watkins | April 15, 2005 03:34 PM
Indeed, one point I'm trying to make is not that something that is popular isn't good but that it isn't necessarily better.
The other question I have regards the screw-up ratio. I wonder: Does the ration really climb? Or does it just become more obvious?
Maybe there are hundreds and thousands of successfull projects done in technologies that we have only ever seen used in screw ups that no one ever talks about. Maybe there are thousands of screw-ups in technologies that we think of as being really good but never hear about.
It's a similar argument that says open source produces better software than closed source. Really? where's the proof? It certainly produces MORE software, faster but is it really any "better" or "worse"?
Honestly I don't know. Run some software metrics over your favourite open source projects and maybe you'll be surprised :)
Posted by: Simon Harris | April 15, 2005 05:29 PM
Well said simon.
The RoR noise has died down now anyway I think. Now I might be able to get back to my day job in peace.
From my limited experience, technology turns out to be the least of the problems in most projects.
It does becomes a problem when an idea or "solution" was sold to someone non-technical (GoldOwner for instance), on an incorrect technical premise (such as: use a rules engine and you won't need to write code any more ! it will be so quick, just a few clicks and your there !). incredible, but true.
Posted by: Michael | April 16, 2005 01:06 PM
Remember that system you tried to write that got lost somewhere amoung web.xml, struts-config.xml, tiles-config.xml, ejb-jar.xml, applicationContext.xml, DTOs, services, .tlds, JSP tags etc?
Well, that's it I suppose. That's the real problem Rails is trying to solve, just trying to make development a little bit more straight-forward so we can focus on actually delivering value to our customers.
If it actually succeeds in this is up to you I suppose, but it should definitely warrant your interest. What if you're unknowingly spending your customers money and time on things that could be so much simpler. Of course, you can't investigate every single claim but when so many people you trust is telling you there's something going on here then you're being irresponsible not investigating.
Posted by: Jon Tirsen | April 17, 2005 05:09 PM
"web.xml, struts-config.xml, tiles-config.xml, ejb-jar.xml, applicationContext.xml, DTOs, services, .tlds, JSP tags etc?"
Indeed, but I don't think I am alone in saying that I don't find that stuff too difficult? I mean really... it isn't that hard. That is the price you pay for flexibility (the real issue is if you want that flexibility. I do.).
I would rather "waste my time" building a system in a stable platform, that is relatively future proof in terms of what you can run it on (Websphere on mainframe - if you must !), then building it in whatever flavour-of-the-month web framework happens to find its way into my RSS feeds.
Posted by: Michael | April 17, 2005 07:00 PM
I am sure that ruby on rails could be/is a great platform - but all the noise about it - is it *really* honestly about delivering more value to the customer? or is that just a cliche that developers (who are very sharp people, after all) have caught on to that allows them to play with the latest technology?
(sorry to be cynical, but I see a lot of that).
Ruby was a lot of fun, I have been using it with the FreeRide IDE that came with the "bundle" of tools and doco (more then a year or two old now, I must confess). But I just don't see myself recommending a toolset like that, where the whole IDE drops its guts at the first sign of an unhandled exception in your code - not very professional.
I know, there are lots of other ways to work with Ruby now... but still, I am trying to compare it to something "mature" like J2EE with Eclipse, or VS.Net 2003 and its "standard" toolset.
Perhaps the consolation prize will be JRuby and Ruby.net *languages* : would have a chance of having them around in an enterprise environment I guess. I haven't really talked to anyone who has been on a large .Net project yet where the DID mix languages (almost always C#, unless it was a VB port) - there must be some interesting issues/arguments in that environment ! would be interesting to see the aftermath...
Posted by: Michael | April 17, 2005 08:14 PM
Michael, on April 16 you said "incredible, but true."
Don't you mean: "incredible, but incredible."? [non-technical people don't tend to be very credible when making technical decisions].
Posted by: Stephen Kestle | April 30, 2005 04:28 PM