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
9 Comments Added
Join DiscussionI totally agree Johan. Also quick-fixes are mine-fields for creating technical debts http://martinfowler.com/bliki/TechnicalDebt.html and architecture erosion.
_You have to design the needed flexibility and you’re *forced* to do it in a clean, generic way._
that’s the problem: you are not really *forced* to do it this way, but you *should*. that’s the command pattern emerging again: poory documented pseudo-generic modifications of the MDSF.
Hi Marcos,
As I stated in the article:
As the Model Driven Software Factory is also a software system, you’ll have to fight the Commando Pattern at that level too!
You’re right, it’s the same problem. However, the mindset when developing MDSF is quite different, especially when the MDSF is developed by a different team or a technology provider.
You can of course always hack your way out of any boundary, so real enforcement isn’t possible. But I think MDE really helps you in focusing on generic solutions instead of quick fixes.
Hi Johan,
I don’t think having to fight the Commando Pattern is a good idea. I would say it is much more preferable to play with it. If you are agile, the Commando Pattern does not mean “Quick and Dirty” at all, it is your usual way of maintaining your software. And a real way to the agility is the good Architecture. Having a good architecture, you can response to change and there is no matter of being quick. The Commando Pattern is your force, and you don’t fight it.
And I don’t see why MDE can not lead to agility and Commando Pattern as an allie. If there is not the desired flexibility in your model, then you have to re-think your model. With good architecture, re-thinking your model should not impact your development, and you should be agile on this point to.
Hi Nicolas,
In my opinion there’s a big difference between “being agile” and the Commando Pattern.
The Commando Pattern means that you just fix a problem without any thought about clean code, refactoring, the way a code base is organized, etc.
Agile development is centered around YAGNI. YAGNI stands for “You Ain’t Gonna Need Itâ€, i.e. wait until code actually needs to be written before writing it. This doesn’t mean that you should quick-fix everything. It means: finish your current iteration (including all necessary tasks like applying design changes system-wide) before executing the next one. It also means: don’t over-engineer.
I think the real challenge in agile development is to find the right sweet-spot between over-engineering and quick-fixing. YAGNI doesn’t mean you shouldn’t introduce abstractions or other design changes, it just means you need to balance/discuss the “needs”.
Back to MDD this means that your Model Driven Software Factory should grow evolutionary based on the needed flexibility in the applications build using the MDSF.
I agree with the differences between “being agile” and Commando Pattern. In fact, I would say both are needed, and there should not be incompatible. In my mind, “Quick” does not mean necessarily dirty, we spend a lot of energy to convince people that a good architecture can lead to quick development whith no technical debt.
I totally subscribe with the YAGNI approach, which (IMO) takes place more in the conception phase than in the development phase. Development phase is still very short in an agile process and should not exceed a 1h cycle.
Back to MDD, why it should be different ? does your MDSF should not have the same needed flexibility than your applications ? To my mind, the most convincing MDSF should be build with itself, giving the same flexibility to the applications, it has itself to evolve.
>To my mind, the most convincing MDSF should be build with itself, giving the same flexibility to the applications, it has itself to evolve.
I do not fully agree with this statement. Yes, it is a good sign that your MDSF is powerful enough to bootstrap. However, this depends a lot on the domain you target with your Model Driven Software Factory. If you target insurance applications it isn’t a good sign that your MDSF can also bootstrap. In this case it is probably a sign your MDSF isn’t domain-specific enough.
In my opinion bootstrapping shouldn’t be a goal. Targeting the chosen domain as good as possible should be the main goal for a Model Driven Software Factory.
Yes, bootstrapping should not be a goal, but if you achieved it, it’s really nice to have the same flexibility in your Model Factory. And I don’t see what could be so specific in a domain like insurance applications, that a generic MDSF could not adress. Do you have any usecase in mind ?
>I don’t see what could be so specific in a domain like insurance applications, that a generic MDSF could not adress.
A generic MDSF can of course address a domain like insurance applications. However, if you build a specific MDSF for the insurance domain it can be much more domain-specific and hence gives you more advantages (higher abstraction, less code lines / model elements, easier to use for domain experts, etc.). Such a domain-specific MDSF can only be used to build applications in the insurance domain, hence it cannot be used to build a MDSF (i.e. it cannot be used to bootstrap).