What is the best software to use for automation? That is the age old question. I remember having this debate more than 20 years ago when I was working at White Sands Missile Range in New Mexico. And today, as I read people’s comments online I realize not much has changed. We have made tremendous advancements in technologies, newer protocols, faster computers, and a multitude of automated test software solutions, but the question of what is the best software to use is still unanswered.
Every programming language, when compared to another, has a set of distinct advantages and disadvantages. Some execute faster, some are easier to program in, some have graphical user interfaces, and others are geared to a very specific task.
I have been writing automated software for more than 25 years now. I have written in just about every automation control language out there and I ask this same question regularly: “What is the best language to develop this solution in?” Having done this several times, I have broken the question down into four separate questions to help me pick the right tool for the job.
#1 What is the time to market?
When we answer the ‘time to market’ question, we are talking about when the software must be complete and operational. For many of us the answer is “Yesterday!” which directs us to the buy versus build decision. In many cases, it is far more costly to build software than to buy it—you should always entertain the idea of buying in your decision tree.
Looking at the time to market question, strictly from the build perspective, we have to approach the problem in terms of man hours multiplied by the cost of an hour, then double the estimate since software is seldom finished on time and on budget.
The knowledge skills and abilities of our developers will be a large factor. Often the best platform is one they already know. The learning curve of a new language is often like retooling a factory; technology changes will cost you down time and productivity in the beginning. Few languages present a large enough advantage in long term savings that justifies the learning curve and productivity loss to switch a whole project. But then again, some do and it is a tough pill to swallow!
What we have to realize here is that “All software is in an investment!” Whether you are buying it, developing it yourself or getting freeware off the web, software is an investment in both time and money. Since we all know time is money, we have to think in both terms of cost and time to market.
#2 What are the future supportability requirements?
The life of any software package is an unknown. During initial development we can speculate as to the expected life but the fact is we really don’t know what computing will be like 5 or 10 years down the road. This makes future supportability a difficult question to answer. It is difficult to spot the next great technology or trend in its infancy. We know adaption of a technology is a slow process largely because people in general are resistant to change. Equating this to supportability, one can conclude a more popular, well adopted platform will have a longer life and be easier to support years down the road.
Using the Visual Basic/Delphi example… I am sure most of you have heard of VB, but few have heard of Delphi. Though Borland’s Delphi™ was a more robust programming language based on the Pascal, it had limited availability of developers making it much harder to support.
#3 Flexibility and Integration?
This means many things to many people, but to me it means two things: 1) How hard is it to take something and make it do what it was not originally designed to do, and 2) how well does the software play with others? I never ask, “Can a programming platform do something specific?” Instead I ask, “How hard is it to do something it was not designed to do?” If it can be done in a few lines of code, then I see it as having flexibility. Integration in general is a good thing—being able to use other off-the-shelf tools and various languages can help cut time to market. For example, using Microsoft.NET™ you can mix and match programming languages and compile them all into one solution.
#4 What are the requirements of the project?
By far, the biggest factor is always going to be the specifications of a project. The devil is in the details and sometimes the details dictate the technology. Instead, we need to keep the details of the requirements technology neutral, wherever possible. The hardest thing to do in technology selection is to isolate details of real requirements from any technology centric paradigms, leading to a skewed or limited pool of technologies meeting the specific requirements.
