Why programming is much harder than modeling?

Why programming is much harder than modeling?

Yesterday Rafael Chaves wrote on Google+:

1:48 AM (edited) – Public
“There is something confusing about the idea of good modeling being hard. After all, all one is doing is describing how the system is supposed to work without having to worry about the implementation details. If one can’t do that, then how is one supposed to manually create a correct, working system?”
Well put, +Thomas Mercer-Hursh!


Just wrote a post about that on my blog:


It’s interesting to see that some people believe that modeling is harder than pure and classical programming. Not only I agree with Rafael that this is not true, but I have the opposite opinion. IMHO, Programming is much harder than Modeling. When you build a program, you are performing (at least) five tasks:

  1. Modeling the surrounding world (or the domain)
  2. Modeling thee underlying executable platform.
  3. Modeling the applicative user needs (application or user requirements)
  4. Merging these three models (synthesis) into one that will be executable.
  5. Deploying the solution in a real environment.

On the contrary, when you are modeling, you concentrate only on one aspect. The problem of merging models comes only later.

So this is why programming is a noble and difficult art, much more complex than modeling. Programming (a contraction of “program engineering”) is a very complex synthesis of the three models pictured below, and probably much more:


This idea is not new. I remember a guest talk given by Michael Jackson, a long time ago,  at the second OOPSLA conference mentioning it. I was very lucky to listen again to these ideas at the Cambridge celebration of the work of Tony Hoare in 1999 where Michael gave a talk on “The Real World“:


In this talk, Michael Jackson refers again to the inspirational work of Brian Cantwell-Smith by borrowing the now classical representation of the central nature of programming:


Looking at this illustration, we understand that the central issue of programming is to build a complex composite model that will bridge the world and the machine, under some difficult constraints.

All this also explains why we should pursue all efforts on software modeling. The most difficult task is merging all models to produce one program. We know two things:

  • in specific cases this is possible and has been achieved by simple code generation techniques
  • in the most general cases, this is likely to be beyond reach for a long time

But we know also that having clean, clear and rigorous models of the domain world, of the platform, of the application requirements, of the QoS constraints, etc. will make easier the life of the programmer, specially if these models may by automatically processed.

In this view, the OMG tentative to propose in 2000 the MDA(tm) initiative with fuzzy correspondences between CIMs, PIMs, and PSMs may be considered now as a very naïve simplification, not very helpful. But it had the advantage of emphasizing the hard problem of explicitly dealing with the world (domain or CIM/PIM) and the machine (or platform, PSM).

This entry was posted in Modeling, Programming, Uncategorized. Bookmark the permalink.

9 Responses to Why programming is much harder than modeling?

  1. I do agree with your view here, Jean. But my point on my blog post though was that it is possible to fully address the requirements for an application without (consciously) doing #1/#3 (or else Domain Driven Development would be more popular these days), and sadly that commonly happens.

    A clear separation between modeling the domain/application requirements and addressing the technological aspects is indeed a much needed change in mainstream software development. My current work is exactly towards building an environment for developing and deploying applications according to that view: all a developer can do is #1 (model the domain) and #3 (model the app domain-centric requirements).

  2. would say, it depends: in 1-3 one matches from the “infinite richness of the world” to models. In 4. one ‘only’ maps from the limited richness of models to program.
    So long |=

  3. lepine says:

    I do think that programming tools have not evolved much since 30 years : IDE are just improved notepad, not much about modeling. UML is unfortunately stagnating because it has been designed by academics more for descriptive purpose than for really modeling. Do we have any tool today which allows to create some instances of some classes, call methods on them to simulate some scenarios ? Only one can do so: BlueJ but it is aimed at schooling not at professional programming. One day someone would do it : he would be the Steve Jobs of programming.

    • jbezivin says:

      You are rigth. Programming tools have not much improved in the past 30 years. If we compare the Eclipse IDE today and the Smalltalk IDE in the 80’s, we do not see much enhancement. Paraphrasing a popular quote, we could say that the Smalltalk-80 browser is an improvement over many of its successors.

    • jbezivin says:

      Sorry but your statement:

      “UML is unfortunately stagnating because it has been designed by academics”

      is wrong.

      UML has not been defined by academics. UML is the result of an industrial consensual process done under the umbrella of the OMG. Academics had no direct official voice in this process, just a folding seat to observe the decisions.

      There has been some external academic initiatives trying to influence the OMG process. The most known is the pUML or Precise UML Group still active at:


  4. vhanniet says:

    Jean: I think your definition of programming is the big one “all steps to get in the end programs driving computers to serve user’s needs”. In this top>down view, modeling in #1, #2 and #3 is an activity among others and obviously less hard in itself than the whole stuff.
    On another end, in a bottom>up view, what developers – AKA “programming” people – are doing is generally also just a subset of the whole stuff: they just do directly #4 & #5 relying, in best cases, on given material for #1, #2 & #3 (or not!). And what we usually call “programming” is just writing “programs” in programming languages that will give something to appear on a screen and a user to tell: “Well… That will do”.
    Modeling #2 may be seen as easiest than programming as defined here. But, IMHO, modeling #1 and #3 are clearly the trickiest part of the whole stuff as #1 means modeling the “infinite richness of the world” (Hi Modelpractise!), and #3 means modeling the “never fully stated business processes” and all the “operative details including doing espresso”.

    As Rafael points out, the easiest road is to bypass the three modeling steps (why bother?) and to search a deal directly between programmers and users (in an Agile way somewhat ;D). The strongest road is the Model Driven way, if we call strong something that will reasonably survive to time at reasonable costs. And the smartest one, the Grail, is to walk on the strongest road and to hide things so that everyone guess to be on the easiest one…

  5. TY says:

    I like Jean’s picture “What is a program?”, and also like to use the comdepts o programming / program and modelling / model in a relative pure and narrow sense (like as Vhanniet? Hi!). In fact, in this sense, they (the domain models via #1 modeling and the application platform ​​software / program) are relatively independent, and this is the basic feature of the model-driven application (MDApp) I proposed.

  6. Pingback: Can Zhu Bajie Be a Fashion Model? | THINK IN MODELS

Leave a Reply to jbezivin Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s