or: Why your team shouldn't use Virtools
This article is not meant as a rant, but more as a warning for potential Virtools customers.
Its focus is only on conceptual problems, not on actual problems with the software.
Multiple Developers
The biggest and most outstanding problem with Virtools is that it is impossible to have multiple developers working on the same project.
There is support for importing smaller parts of a project, but the problem always is that it is impossible to isolate one part of functionality in one part, such that it can just be imported without interaction (although that is not supported either). It always needs to modify some global variable, change the flow around it a bit, or something similar.
Version Control
On the two projects i have worked on using Virtools, we used a "token" (ranging from toys to tomatoes), and the developer with the token had the "write permission" to the project file.
This works ok, although only one man can work at a time while the others can try to come up with ways to solve a specific problem and then wait for their turn to do it all over again in the project file. But the real problem comes when something breaks! Because the Virtools file is just a big binary file, it is impossible to use a version control system on top of it, and Virtools does not provide any "diff" program to tell how two versions of the same file differs.
What this all boils down to is that when something breaks, everyone looks at the guy who made the thing that breaks, and the guy who made it break (the guy with the token) - and the guy with token now has to remember exactly how the file looked before he started editing it, and then trying to find the thing that made the first thing break. For developers who are accustomed to, at any point in time, be able to find out what changes he has made to a program, which files and what lines, the Virtools way is just horrifying.
Re-Use
Virtools supports importing external files, be that script code, behaviour graphs or other files, but the problem is that it is almost impossible to create a piece of code that is completely independent on other parts of a project.
There is also still the problem that you have to manually import files when they change. This yields many problems, for example, when the file is imported you need to setup all the variables and flows once again.
Documentation
When trying to use a piece of software (and especially develop for it) documentation is king! And the documentation for Virtools is just horrible. Commonly things are explained badly, and in some places the documentation is down-right wrong.
Source Code Missing
Related to documentation, when wrting your own building blocks for Virtools you need to come to terms with the Virtools API - it is commonly designed relatively ok, but some places it is badly designed or the documentation is lacking. Luckily (you think at first) Virtools provides the source code to the building blocks, so you can just look at how the API is used by the guys who wrote the stuff (something that appeals to an open source guy like me). The problem is that the things that are strange, are not contained within the building blocks but within the Virtools library, and the source code for the Virtools library is not provided, so you are left wondering - without any way to know how a specific function in the API works.
Lock-In (suggested by Kevin Jenkins)
When you have designed a something in Virtools it is hard to get it "out" of Virtools again. Your schematics (graphical algorithms/flow-charts) are not easily converted to "regular code". This is a bad thing even if you just use Virtools for proto-typing (and usually you would given Virtools' pricing model). It is also a problem that when "version 2.0" of your product is going to be produced you either have to use Virtools again, or start from scratch.
Another part of this is that the things you learn in Virtools is not easily applied to other products, i used Virtools during the university, and it is hard to see how the things i learned about Virtools is applicable in other situations.
This is just the first five points that pops of my head, many of them boils down to "don't think that Virtools can do things you can do in normal development", e.g. unit testing, encapsulation, revision control, etc.