Venting about my current project



  • I am currently working with a change management system that integrates Microsoft VSS into the vendors point and click IDE. The actual application is an IDE for PLCs and is reasonable in itself.  The numerous WTFs I have revolve around set of scripted events that you can configure in order to automatically do various standard maintenance tasks, or any custom task that you so desire.  These scripted events are run at pre-defined times by the "scheduler".  The complete software package is not cheap and licenses are in the $10,000's, but is actually not to bad for the industry. Of course for those prices you would expect a software a little bit better than what half a dozen monkeys could bang out in a few days.  Unfortunately my expectations have been shattered by having to deal the vendors system when trying to use it to implement a solution for one of our clients.  The following are some of the things that really just grind my gears:

    1) Events can run either a vendor supplied standard script or a user written custom script.  The same code for a vendor supplied script can be shared amongst multiple events.  User written scripts have the text of the script embedded into the event itself - Thus multiple events cannot share the same user written code.  This could be a nightmare to maintain unless you do what I did and hack the vendor's set up and made my own script look like a vendor supplied script.  Of course when the next vendor update comes along it may well blow my entire script setup away.  So I had the choice between maintaining the 40 or 50 copies of the same source code in separate events, or the potential that a vendor update will destroy my carefully crafted system.  I chose the latter as  it was the least painful choice.

    2) If you write a custom script, you get the choice between writing it in either VBScript or JScript.  But vendor supplied scripts can only be written in VBScript.  JScript has better support for objects (you can have constructors that pass in values), and better error handing (try/catch versus "On error resume next" - VBScript doesn't include "On Error Goto" ).  So in order support my choice in 1) I was forced to write in VBScript even though the system can execute JScript.

    3) VBScript is not that bad a language (except if you allow for the bizare behaviour of parentheses (http://en.wiki.mcneel.com/default.aspx/McNeel/RsParentheses  and a whole bunch of other things).  So you wouldn't think that the vendor could screw it up too much - well they did.  Their choice of extension for their script files is ".VB" (Visual Basic), not the MS defined ".VBS".  I found out early on that if you load a file with the extension of ".VB", but was really VBScript, into Developer Studio, then Developer Studio would by default "helpfully" change the syntax to that of VB.  Of course it would do this silently and the changes that it made would break a VBScript file.

    4) I queried the vendor on their choice of extension name, and got this reply:

    "In response to your earlier question regarding editing the .vb scripts in [script system], our Engineering Group recommends a simple text editor, such as Microsoft Notepad, to make modifications."

    And this is for a product that has licensing in the $10,000's

    5) The scheduler itself is a fun product.  It simply queues up the starting times of various events, and runs the scripts when the current time reaches the configured start time of that script.  Nothing wrong with that, except that it is written as a forground only task, and has to be run from a logged in account, and that the vendors other software has to have admin privileges in order to run.  That makes for fun if you have a client that wants to run the scheduler from a virtual server - ie no console.  The client's IT doesn't like the idea of an account with admin privileges being continually logged in, let alone how it affects SOX compliance.  And don't even ask about trying to run the scheduler as a service - the vendor's system can't do that for various reasons.

    6) All system configuration is held in VSS, but the vendor's update software isn't really aware of VSS.  So that when you get an update, it starts off by asking to manually checkout various things from VSS before running the update, and then you have to manually check them in afterwards.

    7) The vendors idea of storing a directory full of scripts into VSS involves zipping the scripts up into a single file and storing *the zip file* in the VSS repository.  So you get no source control on individual scripts.

    8) We won't mention the documentation of the vendors scripts, well mainly because a lot of it is non-existent. Actually not non-existent, just that I have been told I can't see it.  The vendor has written some custom OLE automation classes to assist in running their scripts.  The trouble is that these classes are not mentioned in their normal documentation and when I have queried the vendor in order to get some help, I have been told multiple times that any such documentation is for internal use only.  It was only when I jumped up and down a lot did I even get a list of error codes returned by these functions.  Of course the list is incomplete and the desciptions are not very helpful either.

    And that is enough venting for today.

     

     



  • In my experience the following is true:

    If a piece of code is expensive, it does not mean that it is good, it just means that it is just expensive.

    So don't assume that just because you pay 10k per license that its any good. It just solves an issue (barely) that there is no better solution to (at your disposal).



    Having said that, I feel your pain!



    Edit: Why not use the user-defined scripts and create a script that generates the 40-50 copies (renamed I assume) and avoid the whole VB mess and just use JScript?



  • @OzPeter said:

    I have been told multiple times that any such documentation is for internal use only

    A lot of vendors pull this one on you. It always means the same thing. Here's the translation:

    "Our company policy says that we have to have documentation on this. Our bosses told us to document this. We told them that we had documented this.

    However, we did not document it, and now we must prevent anybody from finding out.

    When challenged, we will emit things that look like documentation but which we really just made up, and are complete nonsense."



  • @dlikhten said:


    Edit: Why not use the user-defined scripts and create a script that generates the 40-50 copies (renamed I assume) and avoid the whole VB mess and just use JScript?

     

    All the event definitions are stored in single in VSS using a custom binary format.  To circumvent the system I would have to completely reverse engineer the entire system and that would make my solution even more complex and fragile.  And if I was the client and I was presented with such a non-standard solution I tell the supplier to go away and come back with something more reasonable.



  • But, how do you insert the scripts in the first place? I mean there has to be a registration mechanism... Ask them if you can tap into it externally via. any language.



  •  Here's an interesting article from Joel on Software about software pricing: Camels and Rubber Duckies.
     



  • I bet you work for FANUC.  (I used to)

     



  • @Outlaw Programmer said:

    Here's an interesting article from Joel on Software about software pricing: Camels and Rubber Duckies.
     

    That is an awesome article.  Thanks! 



  • At least be glad you are working in a language that supports error handling.


Log in to reply