Should you script your way to a solution?

I was asked to create a quick, Microsoft-based solution for data migration while upgrading clients to the latest version. I needed to come to a decision on whether to use a scripting language (like PowerShell) or to use fully fledged compiled language (like C#).

The following are some of the advantages and disadvantages for scripting your way to a solution:

• In general, a script will run slower as it needs to be compiled on the fly to machine language for it to run (scripts, generally speaking, fall into the interpreted languages bucket). Taking this into consideration, a script is not your best option if performance is a requirement. 


• On the other hand, it is easier to customize a script as a lengthy build process, often done by a Configuration Management team, is not needed. This increases the agility of iterative development so time and money could be saved. You can also save on engineering costs as you can have non-developers (e.g. service personnel) maintaining the script without the necessity of pricey IDEs (VS comes in mind), build tools, etc. 


• With scripts, you are missing out on the luxury of code verification that is done as part of the build process. 


• It is easy to embed scripts in XML, HTML and such. This is a big advantage. 


• Scripts are usually compatible with wider selection of platforms. 


• As the creator of the script, you most likely had its intended use in mind while writing it. Unfortunately, it is easy to tamper with script and change its behavior. A small, accidental change, can cause it to explode, or even worse, it can trigger unexpected behavior (I remember spending hours fixing such a bug). Also, not so accidental change e.g. malicious code, needs to be considered. When possible (see below otherwise), It will be better to have the scripts on the server side, far away from prying eyes. This approach will mitigate the risk of misusing you script (maliciously or accidentally). 


• Client side script can expose your Intellectual Property and jeopardize the security (For example, Including the connection strings). Your competitors can easily read and learn from the business logic implemented in the script as it is essentially a plain text file (binary files can be reverse engineered as well but in a less straightforward manner). As mentioned above, I would avoid shipping (some) scripts with the rest of the client side deliverables. 


• In case that script functionality is needed on the client side, you can probably make use of the following techniques: 




• VBScript Remote scripting can be used to run scripts on the server as if they were client side. 


• Obfuscate the script. In case of VBScript/JScript you can use Microsoft’s Script Encoder. Keep in mind that a determined individual will probably be able to work around the encoding (as it is not encrypted). 


• Make the script's final distribution version considerably less readable by getting rid of the comments, deleting white spaces and using bad naming conventions. You can write a script to do that LOL. 

I am pretty sure this is not an exhaustive list but probably will be sufficient to get you going. I would be happy to hear more advantages and disadvantages you may find.

I my case it’s a no brainer. Script it is.

Good luck!