GC

Subcontractor

Field Service

Home Builder

Manufacturing

Custom Solutions

 

DocuWrx

844-DOCUWRX

DocuWrx is a premiere FileMaker developer. Our flagship solution, Kosmas, is an end-to-end vertical market solution for the construction industry. DocuWrx also creates first class custom business solutions for many different industries including hospitality, retail, property management, healthcare, manufacturing, and many more. If you are looking for a custom solution for for your business or are interested in Kosmas, inquire below.

Custom Kosmas

The Benefits and Drawbacks of Modular Scripting

In this entry I will be describing my experience with writing modular scripts in FileMaker Pro 13 Advanced. A modular script is a script which operates independent of context. This can happen in a variety of ways; a script can derive its context through clever use of the Get () functions and consistent naming schemes for tables and fields, or via parameters. Ideally, a modular script can operate independently context altogether, requiring neither of the above techniques. However, the demands of real-world usage often make such a stringent adherence to theory impossible. To make sense of my findings, it will help to have an understanding of the environment in which I am developing. At DocuWrx we are developing a SaaS ERP software package called Kosmas, with over 60 individual modules ranging from Human Resources to Work Order management. At the point of writing, the vast majority of the underlying schema and layouts are already completed, and any retroactive changes are made with this in mind.

Some of the drawbacks in trying to develop modular scripts for such an environment can be difficult to overcome and in some cases it is simply not worth the benefits to completely rework an existing system. In a program as large as Kosmas, managing development time for any particular task is paramount. Making even a simple change in one script can have huge implications. For example, in our efforts to offload some of the sorting and searching functionality to the server in order to increase performance our development team identified an opportunity to replace hundreds of scripts with only a handful of scripts that can perform the same functions. In order to solve our particular issue of performance over WAN this major redevelopment was necessary, however it requires a large amount of time and resources devoted to changing a system which already works, and thus delays development of new features. In addition, moving to a centralized method of performing those functions raises the possibility for errors and exceptions to occur. In a schema as complex as the one found in Kosmas, it can be difficult to keep a unified scheme for naming tables and fields. Although in 99% of the cases the methods we have implemented in our modular scripts can be relied upon to gather the correct context information, it is likely that we will run into errors because of unforeseen discrepancies. In a solution designed from the ground up to work in the way we are attempting to steer Kosmas this would be a non-issue, but because we are attempting to adapt a new technique to an existing solution the potential exists for problems to arise.

It isn’t all gloom and doom for modular scripts though! Many of the benefits of modular scripting can be realized even in development environments which make adaptation difficult. The primary benefit of a modular script is of course its reusability. A modular script can not only be reused in a solution it was designed in, but can also be applied to several other solutions and even sold as a bolt-on addition to other developers. Another benefit of having one script serve as a central nexus for similar tasks across multiple areas of a solution is that it simplifies both design and troubleshooting. By using a standardized method of performing any given task, developers can use an established design scheme rather than reinventing the wheel over and over again, and when something does happen to go wrong, the error is often glaringly apparent as there is only one process to comb through, rather than several customized iterations of the same task. The most important benefit of reusability in the case of Kosmas is the time saved in development. By coming up with one solution, we can drastically decrease the amount of time we spend in both development and planning. We can establish one method which we know any additional modules must utilize, and build them accordingly.


As with most other decisions in a development environment, choosing whether to use modular scripting versus using several customized scripts is not a black and white decision. The environmental factors must be considered, and the benefits must be weighed against the costs. Hopefully some of my thoughts on the matter can make this issue a little less gray for some of you