CodeFluent Entities: How did we get there?
For this 100th post on the blog, we thought it could be a good idea to share a little bit of history about the product and where it found its roots.
Although we are now very clear about the positioning of the product and the key benefits of Model-Driven as we explained it on our company blog yesterday, it would be wrong to imagine we woke up one morning thinking we would create the next generation model-driven software factory.
So what were our observations and our goals when we started to design CodeFluent Entities?
1. Avoid redoing work as technology evolves
The first motivation came from our field experience on many development projects. We observed that we were repeating a lot of low value-added tasks. As technology evolution accelerates, the feeling of redoing always the same work a different way led us to find an approach to define functional elements in a sustainable way.
2. Easily deal with user change requests
Separating the functional elements from the technology-related implementation quickly gave us an obvious benefit in terms of change management. It is easy to continuously adjust design of entities, properties, relationships and rules once these elements are centralized within a single model. And one thing we know for sure, whatever the methodology or project, is that functional change will occur, as it is illusory to control it.
3. Connect layers with no effort
Another key element that quickly became obvious as a target was to be able to make sure all the generated pieces work together. This is “by design” in CodeFluent Entities approach but it took a lot of effort to get there and it also explains most of our design decisions. For example, the development of CFQL (CodeFluent Query Language), a simplified yet powerful language to describe methods dealing with data, was initiated to provide the minimal concepts to encompass the needs at both data and business tier.
4. Resolve once, benefit everywhere
The ultimate goal we targeted was to ensure the best coding patterns and solution could be deployed everywhere across the application. Producing the code automatically from a model made this goal realistic and we pushed the ability really far through the aspect dimension that allows anyone using the product to extend the standard features with his own best practices.
As a conclusion, “smart laziness” was our primary driver, and we just wanted to make the business software development process easier.
Of course, we had to theorize a bit to get there, but we did not start with the theory, as we are basically field people with real life project experiences.
This simple vision of key goals we were pursuing as developers map directly with the key benefits of our offering that decision-makers at our customers have observed, and that we have formalized in our software development white paper as our tenets.
Daniel Cohen-Zardi, CEO