There's a special magic to catch-all dismissals of new technology. Usually, they start out being fairly generic and vague enough to sorta pass by with enough waving and implied assumptions. But that only works for so long and soon the catch-all dismissal must retreat to higher ground seeking to be ever more generic, vague, and, of course, meaningless.
I'm sensing that "does it scale?" is experiencing the end of its run along this course. A general understanding that scalability is achievable with most modern web-development platforms has left a void for the role of quick dismissal. But what was lost on scalability is quickly recouped with the advent of... wait for it... Maturity!
Maturity is such a wonderful blank that your brain can readily fill with any property that fits for the moment without even being conscious about it. Hence, most everything can be attacked for lacking maturity. It's a great joker that fits in any hand of argument.
Its greatest fallacy is inherent in its close ties to absolute age. Unlike the growing of man, technological progress is less determined by the passing of time than it is the expendure of attention and determination. A focused burst energy, a large enough set of eyes, the right ideas can all be drivers of "maturity".
That is when maturity is played as meaning something more specific, like...
Friendly (easy to get started with)
Polite (reasonable reporting of mistakes)
Dependable (free of critical run-time bugs)
According to these definitions, some projects remains immature years after their premiere, others achieve it in much shorter time.
So please, take the joker out of the deck and replace it with arguments of specificity and clarity.
Challenge by Matt L. on April 05, 15:59
You make some very good points there. Unfortunately, people assume the longer something is around, the higher the quality. Probably because they make these assumptions in other parts of their life as well (would you be more inclined to hire the new housing contractor on the block, or the one with an established record?) I think the problem lays in the fact that most people do not understand the nature of software development ... which is of course all the more reason to go with the developers perspective, instead of the clients (re: "Hire the right clients" http://www.37signals.com/svn/archives/001053.php )
Challenge by norseman on April 05, 16:42
What about Documentation? I have worked with people that have cited a piece of software as more mature than a simularly aged one since "It has better documentation" [read has more books published on it].
If you are looking for arguments of specificity and clarity, I just wrote a comparison piece between Hibernate and ActiveRecord which you can see here on the ServerSide. http://web1.theserverside.com/news/thread.tss?thread_id=32968
I tried to be as balanced as I can, but my opinion is that Hibernate's is a good example of why the 'Maturity' argument still carries water. There are a lot of complex use cases that a mature software package will address that a new one just hasn't seen yet. This doesn't mean that a new one can't or won't address them at a later date, but its difficult to write a project based on promises rather than existing code.
Matt wrote: "Unfortunately, people assume the longer something is around, the higher the quality."
Ruby's been around longer than Java, has it not? Seems to me it has much more to do with marketing muscle than anything else.
Challenge by Matt L. on April 05, 17:17
RE: Tomas, yes, Ruby has been around longer, but Rails has not. Furthermore, from the perspective of the "client", who has never heard of Ruby or Rails, to them it seems new, no matter how old Ruby is. Thanks for pointing that out though, I had forgotten :P
Patrick: That's what I meant by saying by labeling maturity a joker. You're now using the word to mean features. And more specifically, features you need (or think you need). If maturity is merely a label that can be doled out when a given package fits what we think we need in terms of features, why not just get rid of the joker and say that?
By the same approach, one could label Java immature because it doesn't have the feature of change'n'reload on model and controller code or any of the other differences between using something like Rails and your run-of-the-mill Java web framework.
Hmm. Another question regarding maturity is, "How mature is the technology compared to the one wanting to use it?" The methodology in rails involves some very mature coding styles and methodologies.
No more writing bad variable names, table names, etc. Don't Repeat Yourself. MVC structure. Validations, layouts... Unit Testing!
One reason that it takes some people a while to adopt Rails is because rails is MORE mature than any other framework. (despite its age). It asks the writer to code more maturely.
So your point then is to dismiss all possibly of using 'Maturity' as a valid argument then? I'm sorry, as intriguing as I find some features of rails to be, I can't buy that argument.
Maturity certainly covers a lot of ground but age is decent a standard as the next. Good frameworks don't just add features for no reason. A framework which has been used in production systems for serveral years, like Hibernate, is going to have features that somebody needed.
- Maturity (among other things) is 22 Database dialects vs 7.
- Maturity includes an Object Oriented query language vs. SQL.
- Maturity includes the # of users and documentation.
- Maturity includes # of systems produced with the tool and number of people finding bugs.
Maturity isn't a magic catchall dismissal, but there are valid reasons why it should decision factor.
Challenge by Randy on April 05, 18:47
Maturity (among other things) is 22 Database dialects vs 7.
How does this matter if one of the 7 is the one you need (and the other 6 are 90%+ of the market)? What do the other 21 give you besides more bulk.
I tend to focus more on development issues than run-time performance so for me the two important things to come out of platform "maturity" are:
- The code base (and hence API's) dont change as often so I know that I wont have to go back and redo everything later.
- The code tends to work its way into the cracks. This can be seen on new platforms when you find that it solves 80% of people's problems with great ease and the other 20% are difficult because the framework hasn't reached there yet.
I think that when a framework/program reaches the 80% mark you get that explosive growth everyone talks about and the other 20% of the people dont get the hype.
Patrick: So, again, "Maturity" is an abstract terms that can mean anything at the same time as it means absolutely nothing.
Seems to me like "Maturity" is one of those words you throw out when you have doubts about a language or platform, but can't find evidence to support them.
How does this matter if one of the 7 is the one you need (and the other 6 are 90%+ of the market)?
If Rails supports the database driver I need fine, I probably don't care. And the fact that there are 21 other dialects doesn't hurt me in anyway. I care an awful lot if I'm on one of the other databases.
That's the point of mature framework. It has moved beyond the simplest use cases (that serve 80% or whatever magic # you want to use) and starts solving other problems.
I'm not the one throwing out maturity as an inheritant problem with Rails. It will get more mature over time as more people adopt it. And while some developers are free to do pet projects in anything they choose, there is an art/science around Risk Analysis where proven capability, consistancy of platform and the size of the active developer base actually do matter to decision makers.
Actually I think there is some benefit to the term mature (or maturity) when it comes to frameworks. I don't think it is a totally meaningless word (ambigous maybe, but not meaningless). However, I can not come up with a strong argument to back up my point. As a weak argument, I through out the idea of general acceptance. A mature framework is one that has been accepted by the industry as opposed to a new framework that is still seeking this acceptance.
Once again though what does the word acceptance mean? I could through out the words standard and specification, but I don't think acceptance needs to be that strong. In addition, I don't necessarily think that acceptance needs to be unanymous either.
In addition, I think there is also that concept that to be considered mature, a framework needs to have moved beyond its 1.0 release. Something that is still in that pre-1.0-release stage can not be considered mature.
Isn't "maturity" just an argument for the status quo?
Challenge by JeremyJ on April 06, 0:33
I think many people are missing the point - or at least the point as I understand. David's complaint is not specifically about immaturity claims about Rails (although surely this prompted the posting), but about the use of the word maturity at all. It simply isn't specific enough to contribute to a meaningful discussion.
To me a mature technology is thoroughly vetted by multiple independent parties, it has been used successfully by multiple parties on the type of projects for which it is recommended and it is polished and usable from an installation and documentation point-of-view. Of course, we could further question what I mean by "polished" and so on. Depending on the type of communications we need to be more or less specific.
Maturity, in my opinion, is just another excuse not to take a risk. Medium and large Businesses tend to be risk averse - not surprising when one mistake can be cost hundreds of thousands of dollars. However, I think this also makes them blind to interesting new possibilities, and they still tend to put all their eggs in one basket - they choose one technology and stick with it. I know a lot of development time would go in to making multiple versions, just as if five people carry the eggs instead of just one, but at the end of the day, if someone trips you still have more eggs.
Yes, a bad analogy I know. At least it gives people something to pick at!
In my opinion, Rails is getting to the critical adoption phase, it's just waiting to be used for something that a large enough group of people would call a large scale application. Time will tell, but I'm sticking with Rails. If only I could use Rails at work.
Challenge by Maarten Engelen on April 06, 12:36
Jeremy: I think you're right there. The issue at hand is not what maturity is or is not, but the fact that any discussion based upon totally different understandings of a word is doomed to end up in nonsense.
I do not believe that people using 'maturity' are doing so deliberately to avoid the discussion. Among his or her peers the word may well have a very good definition, but people tend to forget they are from a different reference group when having a discussion.
In this light words like maturity, legacy, scalable are wildcards when they are not backed by a meaningful description of those words by the person using it.
Rails is not everything it could be, yet. Something you can't expect from a framework this young. But I agree that having a meaningful discussion needs to address the problems itself and preferably without using the jokers, wildcards, marketing slang, etc. commonly uttered by decision makers.
"Large scale application" is really just a different set of words that get used like "maturity". It would be nice to see someone define what would constitute a "large scale application" so someone using Ruby on Rails could wave the flag when we cross the finish line. Maybe it has already happened. What makes an application sufficiently large scale? Number of users? Requests per second? Revenue? Globalized deployment?
These maturity, scale, and robustness arguments are all examples of Zeno's paradox: so long as we talk about infinitely divisible measurements instead of absolute goals, the tortoise will always best Achilles.
