Every developer starts out simply being told which technologies he will use, but it doesn’t take long before he can choose his own destiny. Selecting technologies for a project is surprisingly difficult. Some technologies are incredibly good for a specific set of tasks but become equally cumbersome or even unusable when you go beyond those boundaries. Sometimes a developer knows that a technology is flaky but it promises such a huge benefit that it’s worth the risk. The criteria for selecting a technology is what I’ll talk about today.

A number of factors come into play whenever evaluating any technology. It can be software or hardware, you still have to answer a set of questions about whether its a good idea. Let’s think about a few of the common ones.

This list is certainly not exhaustive nor in any particular order. It’s arguably short and other engineers may extend it out further too. It sounds odd, but I do carefully consider each of these questions before selecting a new library and hardware. Let’s go over each question.

Does it really solve the problem or do I just want to use it? What a dreadful question to ask? It is one that requires some introspection as to your own personal motives. Let’s say you are presented with a choice of TopLink and Hibernate and you haven’t worked with either but you’ve heard of both. Which one do you choose and why? Sometimes we inadvertently pick a technology that is going to help our resumes later. Face it, Hibernate is probably worth more to your career than TopLink. But what if TopLink is actually better for the scenario and can finish the project faster and more reliably?

This is a difficult challenge as you must remember that a new project is an opportunity to grow professionally and personally. There is also the ability to be forward thinking and realize that a given technology is growing and so more people are interested in learning it and want to work for places using it. Nonetheless, the first issue to resolve is whether the technology will really solve the problem. If the answer is no, then it is your obligation to move on in the selection process.

How long will it take to integrate and build from? You’ll spend some time trying to figure out how to get it to build in your application, packaging and deployment. Some technologies require one download after another to get all the dependencies and can be painful to get setup. Then figure out how to replicate it across all the developer’s desktops. You can put it in source control or someplace else, but the trick is putting it in a place that requires the least amount of individual developer effort to get it.

There is also a learning curve implied here. You will have to spend some time learning how to use it and write code to take advantage of it. Some technologies are poorly document and very complex. The early documentation days of Struts and Hibernate were only vaguely useful. They have evolved and become much easier, but back then the learning curve was steep.

Does anyone at the company have any experience using it? It is really helpful to hear the experiences of those that have used a technology. First, you get their experiences and good or bad, it is valuable. Second, you may learn something about your teammates and show respect by asking for their opinions. You only have to ask yourself if you like it when a developer asks you for your opinion on a design or implementation to be sure if this is a good idea.

How much does it cost and are support agreements available? Some libraries are open source but have commercial licensing requirements. In those cases you really need to consider the costs of a technology and sometimes you rule it out based on that alone. It is fairly common that some libraries require an OEM license, so you end up buying a license for every copy of your product. This is an annoying and time consuming process. The cost can sometimes be steep or completely inconsequential, but the time spent having to buy licenses and configure customers with those licenses is considerable. This may not be an issue if you send a person to install the product at a customer’s site or if you have a web service that you host.

Support agreements can be incredibly valuable if you use them. It happens often that people buy a support agreement and then never call. It’s a lot like a guy with OnStar whose lost but won’t ask for directions. He bought the service but he just won’t use it. Lots of companies buy service agreements for tens of thousands of dollars a year that they never use. Depending on the agreement you may have unlimited tech support and they can often answer a question a lot faster and more accurately than you can research it.

What is the licensing scheme? Some open source licenses are restrictive in how you may use and distribute the component. Some require you to open your source tree to the public. Some require you to only publish your modifications. Finally, some let you do whatever you want with no restrictions.

I believe that this is the most important question to answer. It is not worth even prototyping code if the license agreement is not compatible product’s sales model. It happens often that a developer picks library with the wrong kind of license and several months later he spends weeks removing the code because he can’t sell the product because of the license.

How big is the internet community? The size of the internet community tells you how popular it really is. In particular, pay attention to the number of blogs talking about it and whether it is positive. Look for people talking about their experiences rather than tutorials. Experiences tell you what it is like to use the technology six months or a year from now, how long it takes to learn and the various gotchas. The bigger the community, the more likely it has been successfully used in other applications. If they could do it successfully then you can too.

There is the risk of zealots. These are the guys that couldn’t imagine using anything else ever. I am careful to take a zealots opinion as a grain of salt. I’ve run into too many zealots that want to use fringe languages, strange protocols and really odd design patterns to solve very common problems. I become especially paranoid of these guys when they are involved in language development as they will recommend that your Java or PHP web application be rewritten in something odd and complicated, like Ada.

What are the posts like in the support forum (if there is one)? Forums can be extremely valuable, except when they are accused of censoring. The value is that you see the kinds of problems that other adopters are experiencing and how they solved them. The common problems are often easy to see from titles alone. The difficulties people are having can also be figured out by the number of readers for a given post.

No forum, or a censored forum, leaves you with very few places to turn for help. Even the simplest library has bugs and has corners that are poorly documented so a developer cannot assume that he will never need help. No forum means very little help.

How long has it been available? This one is a little tricky. Some new technologies are just so incredibly valuable that their age is almost irrelevant. Take Adobe AIR and Google Gears as examples of amazing new technologies that only came on the scene a short time ago.

Consider that you are looking at two different Javascript libraries where one is two years old and the other is only three months. The three month old library may not be as well tested, may not have the community, but more importantly, it hasn’t proven that the developers supporting it are going to be there for the long haul. Just imagine getting into a year long development cycle and finding out that the OSS developers for your Javascript layer have decided to move on and now your stuck with an unsupported third-party Javascript library.

How does it impact the schedule? Some will argue that this shouldn’t factor into the decision making process at all. However, we are expected to produce a lot of code usually at an aggressive pace. Scheduling becomes a very important factor because we are expected to continue producing code and product, not researching something genuinely interesting.

The schedule impact can be broken down in several ways:

You then compare the schedule impacts of using a different, equally applicable, technology. Let’s say you have experience in Struts and you want to switch to Tapestry because you’ve heard so many good things. You figure that the Struts implementation may take three weeks to integrate, build, and deploy, but all your reading says the Tapestry implementation will take only a week, maybe two at the most. The difference is the learning curve. Will it take a week or two to figure out the right implementation? How does that affect the schedule now?

Using a new technology requires a lot of schedule padding. The bigger the framework, the more padding. It may work really well and pull in your schedule initially but an unforeseen glitch, like lack of experience with the technology, in your design may use the technology in an odd way and ultimately delay your release by a month or more.

The other scheduling issue, especially when presenting the plan to a project manager, is if the tried-and-true way has nearly the same schedule as the new technology way. Its very hard to argue the merits of a new technology when an old technology takes just as long to implement.

We have looked at some criteria for choosing technologies. To me, the only criterion that is an actual gating condition deals with the licensing terms. The others need to be balanced against each other to see if the overall picture of the technology’s impact is positive enough to warrant the various risks. If all things are equal, then you are left with one last item to consider: your reputation.

Your reputation within an organization is incredibly valuable. Every time you make a great choice your reputation increases. The better your reputation, the better assignments later and a greater likelihood of promotion, pay raises and leadership opportunities. So when choosing a technology, be sure that it’s something you are very sure will work, as success opens doors.