Our prospects and customers often ask us to recommend a development environment for a given application.

A really tough call, for so many parameters come into play when making a decision.

I would like to share few dos and don’ts when picking a language.

• Do not believe that picking the solution from the market leader (IBM then, Microsoft now) is less risky.

  Remember the “you cannot be wrong with IBM!” I do not know who coined this non-sense. Of course you can be wrong with IBM (or with Microsoft now)! Do acronyms like OS/2, PL/I, SAA, a central IRDS dictionary and the likes ring any bell? Corporations have wasted millions of dollars only because IBM told them they could not be wrong.

  I do not know if Java is a better choice than .Net, but it is fair to say that today Java does not appear a riskier choice than .NET. It might just be the other way around: a proprietary environment might find more resistance and less supporters than a product in open source or available under General Public Licensing.

• Some WEB sites, like www.tiobe.com for instance, have developed formulas mostly based on the availability of skilled engineers, courses and third party vendors, to measure the popularity of languages. This is certainly interesting information, but companies should not choose a language based on the number of talents available on the market.

  They should hire developers based on their intrinsic qualities, rather than on their knowledge of a given language. Talented developers will rapidly master a new language anyway.

• The opinion of developers is an interesting indicator. First, they are usually reluctant to use languages before they reach a certain level of recognition, because it does not add value to their resume. By the same token, working with outdated tools makes them look like laggards, one of the worst things in this fast changing industry!

  The ideal scenario for them is to learn and use a language when there is a significant market demand that outpaces the supply; such shortage usually happens when a language has gained enough customer traction to become mainstream (it does not mean it will become mainstream though!). In the Silicon Valley, it is now the case with PHP, or RonR to a lesser extent, for instance. Does it mean that corporations today should go for these environments all the time? Of course not.

  I would suggest this: for non-mission critical applications, it is wise to let developers pick their favorite language. However, for the applications that are critical to the business, nothing comes close to mainstream solutions (J2EE or .NET).

• Some managers heavily rely on reports published by industry analysts. During the 15 years I spent marketing development environments, I remember gaining or losing business, just based on our product’s position on the Gartner’s magic quadrant. While I understand the need for synthetic tools, I strongly disagree with making choices purely based on these reports.

  Analysts and bloggers can create a buzz around a product, but not a lasting market demand. Because of their transient nature, buzzes do not last.

  Last January, I remember attending a presentation given by an industry analyst on the major trends for 2007. The wide adoption of VIsta by corporations was topping his list!! It takes more to understand the market trends than circulating a survey once a quarter to a panel of CIOs.

• Languages usually have a longer life span than frameworks, accelerators, generators, interpreters, etc. Cobol, C, C++ have survived Telon, Forte, Powerbuilder, Delphi and the likes. For the same reason, J2EE is likely to survive Zope, Ruby on Rails, etc.

• I recently found this excellent comment from David McCoy on a forum where the pros and cons of RonR were debated: “IMO, Ruby is just another in a long line of scripting languages that was going to display C, C++, and Java. It was going to be bash/csh, then tcl/tk, then Perl, then PHP, then Python, then Groovy, and now Ruby. What displaced C? C++. What displaced C++? Java. The real question is: what will displace Java? Most likely another statically typed language. I could not agree more with his comment.

Today, there are 2 major environments available: .NET and J2EE. Let us hope that corporations will still have a valid choice in the future between 2 or 3 alternatives.

When given the option, we tend to use J2EE-based frameworks for the non-client part of the application. For the user interface, we would usually go with either Javascript / Ajax or Flex, depending on the customer requirements.

Technical | 3 Comments »