Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A disconcertingly high number of new technologies/paradigms are overhyped (as is evident from replies to this question). Combine this with the fact that being early adopter is inherently risky. This makes evaluation of technology before adoption critical. So how exactly early adopters among you go about it.

I can think of following general criteria.

  1. For early adoption technology must address previously unaddressed issue and/or
  2. For acceptance beyond early adoption technology should address performance
  3. One indicator that something is not right is when there is too much of jargon for technology which is either irrelevant or there is no evidence to back it up

What is your opinion.

Update: 4. BTW, the biggest reason to fear technology is when it is imposed by the tech-unaware management based entirely on number of buzzwords.

share|improve this question
add comment

3 Answers

up vote 5 down vote accepted

A major concern for me is stability. By stability, I don't (always) mean bug free. I need to be able to get 'comfortable' with certain features that it provides, without fear that subsequent versions may break (or eliminate) them. This is why I'm rather pessimistic when it comes to adopting new languages. I need to avoid seeing something introduced in v 0.07 and deprecated in 0.09, only to vanish completely in 0.10 - especially when releasing every few months. But, with any new language .. you sometimes wonder if you hit a deliberate feature or tickled a 'useful' bug.

I also look to see where else something is being adopted, so I can decide if the extra dependency is really worth what we're getting out of it. For instance, if several major OS's started packaging (and using) Google Go, I might feel more confident about pitting it against some current problems and seeing what happened.

I really think it depends on the individual though. Some people are just naturally more inclined to say 'why shouldn't I use it?' instead of 'why should I use it?'.

share|improve this answer
    
But as an early adopter how can you know beforehand than technology is going to stable in the next releases. –  Gaurav Dec 1 '10 at 3:19
    
@Guarav - That really depends on the project, who is working on it and my experiences with them in the past. I trust certain companies and individual developers to try to eschew shifty API's more than others, for instance. Road maps also help (provided they actually apply in light of what is actually happening). Mostly, though .. it comes from experience. –  Tim Post Dec 6 '10 at 12:03
add comment

The process of breaking new technology in means testing its limits. If technology A can be used for x, why can it not be used for y and z as well? The only way to know is to try it out. Thus, I believe that a certain amount of hype is good. It means that people are figuring out what can and can't be done with it. I mean, we know the things that Java are good and bad at fairly well today (even if people don't accept them), but we didn't have a clear understanding when it first came out.

The problem is when you discover that the technology is clearly unsuited to a task and you use it anyway. The point of experimentation is to figure out if something works, not to make it work if it doesn't.

share|improve this answer
add comment

We are in the situation that we know already now that the Java programs we write today will most likely have a lifespan of decades, so it is important to choose technologies and implementations that will have a chance of being maintainable at that time. Fortunately the mindset of Java has up til now been a matter of intense attention to backwards compatability which makes it easier.

The line of thought:

  • We want choice. This means multiple, interchangeable implementations of the same thing.
  • For Java multiple implementations of the same thing means a a formal specification somewhere.
  • The primary source for formal specifications for Java technology came from Sun.

Case in point: Servlet API's. If a web server written in Java does not support the Servlet API it either needs to do so fast, or fade in obscurity.

The latest version of Java EE has some very interesting facilities. JSF 2 with facelets is a nice way to create web pages. CDI hauls in JSR-330 Dependency Injection which is really nice way to glue programs together at a later time than when the code is initially written.

We have had good experiences so far with sticking to technologies with specifications. This means missing some of the exiting new stuff, but it also means not having to figure out the exiting stuff for the previous decade later.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.