Model Driven Engineering vs. The Commando Pattern
In my article 8 reasons why Model-Driven Development is dangerous the first two reasons I stated were about rigidity and flexibility:
- MDD actually introduces a lot of rigidity.
- Models are only flexible where flexibility has been designed.
Both items stem from the fact that Model Driven Engineering (MDE) introduces a double release cycle when used in a software development project. In the first release cycle new releases of an application are created by changing the model and executing the deployment phase again. The second release cycle joins the party when the MDE tool doesn’t support the changes you need to make to your application. In that case you need to wait for a new release of the MDE tool introducing flexibility at the points you need it.
In my opinion such a double release cycle is an advantage! It protects your software development project against the Commando Pattern.
The Commando Pattern
The Commando Pattern is used to get in and out quick, and get the job done. This pattern can break any encapsulation to accomplish its mission. It takes no prisoners.
Although the Commando Pattern is a joke pattern, I guess a lot of readers have used it or have seen it in use. It’s so tempting to do a ‘quick-fix’ if you are in a hurry or if you don’t fully understand the code base you’re working on. And… who cares? Everything works just fine. All tests are green (if you have them).
How MDE fights the Commando Pattern
The Commando pattern may look attractive, but don’t forget:
The trouble with quick and dirty is that dirty remains long after quick has been forgotten.
– Steve McConnell
The Commando Pattern leads to complexity. The first time you use this pattern everything looks bright and shiny, but after a couple of times your code base will become a mess. Why do you think it always takes longer to create version 2 of a software system? And what about version 3? Complexity is killing us!
Besides that, the real costs of a software system are in the phase after the implementation of the initial release. Maintenance, adding small features, fixing bugs, adaption based on user feedback… there’s more than creating an initial version!
Model Driven Engineering gives you flexibility where you need it. Changes can be made on a higher abstraction level (opposed to third generation programming languages) and can only be made at the points where flexibility is designed. If the changes you need to perform are possible within the current MDE tool they are fast and controlled (read more about MDE / MDD speed and deployment).
As said before, if you can’t make the change you need because there is no flexibility in the models at the right place, you’ll have to wait for a new release of the Model Driven Software Factory you use. It will cost you more time than using the commando approach, but it enforces you (or the team building / maintaining the Model Driven Software Factory) to think about a generic solution. You have to design the needed flexibility and you’re forced to do it in a clean, generic way.
As the Model Driven Software Factory is also a software system, you’ll have to fight the Commando Pattern at that level too!
Have you seen the Commando Pattern in action? What are your experiences with fighting it? Please share!
Photo by EdgeDonkey