The complexity of software projects keeps increasing, not only in size but also in terms of the technologies they have to integrate with. Long gone are the days of “simple” data-driven monolithic applications attacking a relational database in the backend. Now we have to integrate with a myriad of NoSQL (or NewSQL) databases, external APIs, a variety of UI libraries,…
To keep up with this complexity, programming languages are always used within software frameworks providing a lot of the basic infrastructure you will need in every development project. And these frameworks are getting bigger and bigger, with more and more options to integrate and configure all components you may want as part of your project. To the point that some frameworks may be doing more harm than good!
As a reaction, the convention over configuration paradigm (also known as coding by convention) is getting more and more popular. All frameworks nowadays follow this paradigm one way or the other.
Convention over configuration is a software design paradigm that aims to decrease the number of decisions that a developer is required to make without necessarily losing flexibility.
Convention over configuration means different things to different people but the basic idea is that developers should focus on the core aspects of the project (i.e. implementing the functionality) while all the standard (i.e. conventional) aspects of the projects are added/generated by default. This could involve simply configuring for you the database backend adding the required dependencies to the project or more advanced decisions like generating the tables in that same database for you, based on applying default naming conventions and generation rules on your object oriented classes. Unconventional options can still be provided by the developer, overriding the conventions at any time.
Does this sound familiar? Isn’t this very similar to what we (the “model-driven community”) aim to achieve as well? Sure, our key principle is not conventions but abstraction but the end result is not that different. By abstracting from low-level technical details we also want developers to focus on implementing the requirements while the MDE tools take care of generating the rest. And when flexibility and detailed indications for the generation phase are needed, we rely on lower-level models (the platform-specific models in the MDA terminology) to allow developers specify/tune all the unconventional details.
To me, the popularity of convention over configuration is a great opportunity to spread the model-driven philosophy. One of the reasons programmers don’t like MDE is their feeling of losing control over all gritty nitty details of the code. Well, we can now explain to them that this is not so different from what happens in all the programming frameworks they love so much. If convention over configuration is good, MDE is even better!
And by combining the two we can easily build “smarter” code generators that rely on the framework conventions to generate more and more of the infrastructure code (and here I include also all variations of the CRUD functionality) from simpler models, moving towards the Pareto Principle for MDE .
20% of the modeling effort suffices to generate 80% of the application code
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Recent Comments