Pareto principle applied to MDD

The Pareto principle (also known as the 80-20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes.

This principle applies to many areas, e.g. “80% of your sales come from 20% of your clients” or “80% of your employee performance evaluation will come from just 20% of the items on your daily To-Do list”

What the rule tells us is that in anything a few (20 percent) are vital and many(80 percent) are trivial, and thus, to improve your productivity, you should focus on the 20% that makes a difference. Investing your time in the other 80% will only produce a slight improvement of your results.

I believe that this principle also applies to the area of model-driven development. I state the Pareto Principle for MDD as follows:

20% of the modeling effort suffices to generate 80% of the application code

This implies that, following a pragmatic MDD approach, we can boost our productivity and benefit from many of the advantages of modeling without the burden of defining complete and precise models. This is the assumption behind the services offered by the portal (btw, the XMI service will be released in the next days, stay tuned). I think that for many companies, this 80% of code-generation will be more than enough or, at least, a good starting point to experiment with MDD before deciding whether to adopt a full MDD-based development process.

Let me give you an example. To achieve a 100% code-generation of a software system we need to fully specify during the modeling phase the behaviour of all required system operations (e.g. using some kind of action language, as the one provided by the UML). However, it turns out that most of the operations (you guess it! around 80%) are simple CRUD (create/read/update/delete) operations, whose number, specification, parameters and behaviour could be automatically deduced from the static model elements in the class diagram! (e.g. if the class diagram contains a Customer class, it is not difficult to see that the system will need to offer operations to create new customers, to update each one of its attributes, … ). That is, with a 20% of the modeling effort (only the definition of the static aspects of the domain) we can automatically generate an staggering 80% of all operations required to query/manipulate the applications’ data (see a couple of case studies we did to validate this result as part of this paper )

For instance, given this model:

we could automatically generate this extended model:

where each operation specification AND body would be completely specified. For those interested in the details of the generation method used in this example, you can check the paper: Deriving Operation Contracts FROM UML Class Diagrams paper or in its extended version: Automatic Generation of Basic Behavior Schemas from UML Class Diagrams

AND remember! this IS just one example, I’m sure that the Pareto principle also applies to other aspects of modeling. Can you think of more scenarios?

Btw, with this post I say goodbye until next Monday/Tuesday. This evening I’m leaving FOR a four-DAY trip TO Cape Breton , following the trail OF my Cabot ancestor.

If you enjoyed this post you can subscribe TO this Software Modeling blog AND/OR follow me ON twitter OR through the portal’s mailing list . And if you really liked it help me pass it on to others by bookmarking and sharing the post using the links below:

9 Responses to Pareto principle applied to MDD

  1. Anonymous says:

    Perhaps that 20% of the code that is not generated is responsible for 80% of the competitive advantage that software produces. We need a study that can examine the productivity claims — I suspect these simple CRUD type functions would be pretty trivial to implement manually, as well.

  2. jordi says:

    These CRUD type functions are not always as trivial as they seem (in a paper that is now under review we check how many errors students had when manually writing those operations)
    but of course, they could be manually implemented with a limited effort.

    And obviously, the competitive advantage of the company won’t be ON that 80% OF the generated code, but I don’t think this contradicts the message of this post. In fact, what I’m saying here IS that you can easily GET rid off OF ALL these less important operations (that represent 80% OF your total) AND focus MORE ON those functions that ARE KEY FOR your product. Even if they ARE NOT that important, you’ll need to implement the CRUD ones anyway, so why bother when you have a way to automatically (and correctly) generate them?. To me, this represent an improvement in your productivity!

  3. jordi says:

    My pareto principle for MDD is being discussed as well in the model driven development forum and model driven architecture groups on LinkedIn.

    Some comment excerpts:

    • I think the pareto rule applies quite well for this approach, provided the tool is appropriate.
    • I should become like that but most MDD is now only generating skeletton code and other a few more based on rather simple CRUD based ORM and straighforward Web pages corresponding to a table.
    • We’ve actually been seeing this TYPE OF results FOR SOME TIME already WITH SOME OF our products AT IBM (AND Rational/ObjecTime) that actually generate complete application, albeit targeted TO a limited DOMAIN: embedded systems. We have had customers IN many areas that have used this TO greatly reduce their development efforts AND TIME-TO-market.
  4. Anonymous says:

    I must say that while participating in development of some business-related applications, I usually saw 80% of complicated business logic (usually implemented as business rule sets) and 20% of CRUD stuff (the same percentage applies to test cases too). Implementation of the CRUD is such a common task nowadays, that I’m sure you won’t be able to gain much by generating it. In e-shop – maybe, but not in an enterprise invoicing solution. Though in such application you have quite complex data structures backed with RDBMS, some ORM is usually used here, and CRUD actually becomes only 20% of code (and 5 – 10% of effort) because on the other side you have let’s say 700 pages OF business rule docs, which normally can’t be automated that easy. DSLs are of a great help in this case, and that is much more important in my view.

  5. jordi says:

    ON the kind OF application. IN the ones I did WHEN working IN a private company (AND IN SOME OF the experiments we’ve done), my 80/20 rule applies but of course, in other domains or when dealing with other kinds of applications, your experience may be different.

  6. Generating operation specifications from UML class diagrams: says:

    [...] artículo sigue la filosofía de la regla del 80/20 (pareto principle) aplicada al MDD para auotmáticamente generar operaciones básicas para un diagrama de clases. En [...]

  7. [...] addthis_product = 'wpp-261'; var addthis_config = {"data_track_clickback":true};Following my own “Pareto principle (or 80/20 rule) for MDD” I´ve always defended the idea that MDD tools should not (and don’t need to) ask developers [...]

  8. James Z says:

    If u r using models to generate crud operations and believe that gives u 80% of ur code, I might have to say the application you are building seems pretty simple with not many business rules. In which case you might as well just use an ORM.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress
More in MDD
Model-driven development of a web browser
Modeling groups in LinkedIn (active)
MDD discussion with Dr. Pro and Dr. Con – Recommended reading