What are the trade-offs of rapid development tools?
Religion and folklore have plenty of cautionary tales of taking the appealing, short-term option, and not thinking about the future. I worry about this when I make bold claims about the speed of creating solutions in Metrici. I need to be more open about the trade-offs.
There is nothing magical about reducing development time. The methods Metrici uses are much the same as those used in other tools (though I like to think we have crammed more into a single platform). But each time saving method has a trade-off.
Delivering solutions as software-as-a-service (SaaS) means there is no infrastructure to buy and configure, no software to install, and common features like user management and security are already in place. SaaS is simpler and cheaper for most solutions. The trade-off is that you have to entrust your data to someone else.
Automation of database and user interface (UI) makes developing a solution as simple as describing the definition and structure of the data. This saves a lot of time, especially for solutions like assessments and management information systems which have transient or frequently changing data definitions. However, generic data structures are not as efficient as specific data structures for large volume transaction processing. The UI can be tailored, but if you have to tailor everything, it would not be as quick as using a more UI-centric tool.
Metrici provides a basic UI and data structure framework for solutions, and you add code for things like calculations and UI tailoring. This is much faster than writing a base program that controls all the database access and user interface. The trade-off is that you have to fit your solution into the pattern of the platform, which in Metrici's case is a web-based application.
Being able to redefine the components you use for development is common in lower-level languages, like LISP and Java, and Metrici similarly exposes high-level development components for modification. For example, if your solution requires a particular sort of graphs, you can create new types that simplify creating them. Making complicated things simple greatly reduces development effort, but you do need to spend time understanding existing components and how to write new ones.
Like a lot of content management systems, Metrici allows data and definitions to be versioned. This means that you can change things without impacting what is already there, which makes it much easier to build solutions incrementally, and much quicker to modify solutions later. But version-managed data structures are more complicated than they would otherwise be, and the trail of old versions means that you never fully remove earlier (and possibly erroneous) data.
To get the benefits of rapid tools without long-term regrets, you have to understand the mechanisms they use and the trade-offs. Metrici is no exception. The mechanisms Metrici uses - SaaS, automation, framework, components, change management - make it a productive platform for many data gathering, content management, record keeping and reporting solutions. As much as I believe they are worthwhile, there are of course trade-offs. If you want a rapid development tool you need to think carefully about the trade-offs, and be wary of promises of short-term productivity, even if they come from me!