With all technology, experience can reveal aspects that could be improved and provide suggestions for new innovations. In addition, one always hopes that experience in the field validates the design decisions that were made during the course of development. Although FARGOS/VISTA™ is no longer a young technology, it benefited in a variety of ways from the experience obtained by its predecessor.
Outside of a purely academic environment, the opportunity to measure the effort required by distinct development approaches is rare, simply because justifying the expense of two (or more) separate development efforts having the same goal is difficult. In an ideal world, the work would be done once at minimal cost, be bug free and engineered to accept future enhancements without requiring a redesign. It is probably an understatement to assert that this ideal state of affairs is sometimes not achieved in software development efforts.
As a consequence of a few such less-than-ideal development efforts, measurements were obtained of duplicate development efforts that used conventional approaches and the FARGOS/VISTA predecessor. It is from these experiences, and other metrics (such as lines of code), that the measurement of a 6-to-10-fold improvement in productivity was obtained. These measurements are, however, often understated. For example, how would you measure a project upon which one developer worked for 10 months and failed to deliver a working system compared to another in which two weeks of work delivered a complete solution and provided a solution to which another group had not even gotten around to addressing? To be conservative, we round 2 weeks up to 1 month and pretend that the other 10 month effort was successful. Likewise, how would you compare 4 months of work by one person against 3 real-time years of a team whose size varied between 5 and 10 over the course of the project? This is something between 15-30 man years of work compared to .34 man years, which would represent a 44- to 88-fold improvement. Rather than make the claim of a 44-fold improvement, we round 4 months up to 6 and convert the 5 to 10 people to 1, yielding a claim for a 6-fold improvement.
So, while a 6- to 10-fold improvement in programmer productivity might seem astonishing, the assertions are derived using very conservative assumptions.
Many practicing programmers work without the benefit of a formal education in Computer Science. One frequent side effect is a lack of awareness regarding the computational complexity of the algorithms they construct. The construction of a multi-threaded, event-driven distributed system is something that many programmers cannot successfully achieve. Some are aware of this and would, as a result of their professional ethics, refuse to undertake such a project; others will assume they will figure it out along the way and won't realize their mistake until much later.
A significant difficulty in constructing complex systems is the number of items that must be managed by the programmer. Ultimately, any software development effort carries with it the requirement to convert the abstract "big picture" into the actual implementation of myriad interrelated data structures and algorithms. While the very best programmers have the ability to keep track of more items than those with less skill, the complexity of a given system creates a barrier to successful implementation. Programmers who are not able to manage the necessary level of complexity will thus not be able to deliver a correctly working system.
The FARGOS/VISTA development model does not just enable, but actually mandates, a development paradigm that reduces the complexity that must be managed by programmers. In addition, difficult tasks are made trivial. Want to pause the execution of a thread on a remote system? This is all it takes:
send "suspendThread" to threadObj;
No use of Interface Definition Languages, which are common to implementations that use Remote Procedure Calls. No need to include header files, much less ensure they are up to date and match what was used to compile the process currently being used on the server. The "FARGOS/VISTA Examples" document provides illustrations of sophisticated applications or tasks that would effectively be impossible with conventional technologies.
The result is that applications that would be beyond the abilities of novice or average programmers become not only feasible but almost trivial to implement. Consider this example from the past: a Systems Engineer, whose programming experience was mainly limited to Korn shell scripts, was able to integrate the FARGOS/VISTA predecessor with a bank's custom network management application during the course of a single afternoon. A second afternoon of work converted the system into a fault-tolerant system spanning two physical sites. If the entire cluster of redundant management servers failed at the primary site, the system would automatically fail over to the cluster at the backup site. When service was restored at the primary site, control would automatically switch from the backup site to the primary. Displays at both sites would be kept up-to-date without creating any redundant network managment activity.