Deep down in every system there is a model.
Weather you see it or not, it is there
The model is the description on what data your system thrives on.
The model describes how your data relates, what properties it has and what that data is called. Whenever people talk about what your system does, they talk in a language that is defined by the model.
Some people keep the model in their heads alone, or in a separate file on their hard drive.
This leads to all kind of challenges when communicating within the developer team and when communicating with the customer; not unlike the whispering game where information degenerates as it passes from mouth to mouth.
This degeneration leads to subtle differences between the database schema and the application code and differences amongst the members of the team as well
These differences are not usually seen by the different parties; everyone involved thinks that they have the correct understanding of the information; just as the classic effect of the whispering game
The differences sooner or later show up as internal incompatibilities and as an increased friction when the parties involved try to be productive and focus on development.
Developers have grown accustomed to this increasing friction that makes it harder to maintain and develop a system the older it is. So when the energy to understand a system overgrows the energy to write a new system they simply start over while chanting “Re-write” so everyone can here. Getting the clients acceptance by blaming earlier developers and poor design choices is easier than it should be; there is not much choice once the system has reached this state of decay.
The developers then often start over with the whispering game and they are bound to fail again, blaming the earlier incarnation of themselves. Around it goes, draining money from the client that has been tricked into believing that this is just how it must be.
Today a lot of us understand that very much pain and decay was caused by not communicating the model to all involved parties and by not sticking to one common model along the system’s lifetime.
We also know that by setting the model in focus we can automate much of the work that was earlier done by hand. So not only do model driven development solve the basic issue with diverging ideas what the system is about, it also allows you to reach the goal faster and with higher quality.
The bulk of any information system is after all about predictable operations on domain objects, their relations and attributes as defined in the model. It is easy to understand that these operations can be handled by a framework, and thus can be implemented once and for all.
Now; 9 years into the 21 century there are still cavemen walking around, producing rotting systems by trusting the whispering game for core definitions. Be advised; evolution will eventually erase them. The stuff they build today will eventually be gone; it will rot and be replaced. If you pay for work like this you are in for a never ending story of rewrites that will cost you money and stop you from earning money.
The quantum leap developers do, when focusing on the model and applying a model centric framework is a wonderful thing to see. You can expect that one developer can do the work of at least 5 ordinary non model centric developers, but the biggest gain is the precision and stability that this approach gives.
Imagine to see a developer that looks straight into the client’s eyes and says “Oh, you want it like that, now I see, no problem”, and never again here “that was not what you said before, we cannot change now”.
Many developers have finally shifted focus from defending their rotting systems, to implement every tiny detail needed for today’s businesses.
Having all developers seeing the same model and having a framework that can act on the very same model is a refreshing, yet so obvious solution to how we as a species can master information and create the systems to handle it.