How can modeling be harder than programming?

One argument often posed against model-driven development is that not all developers have the skills required for modeling. This recent thread in the UML Forum discussion group includes a very interesting debate on that and started with this statement by Dan George:

Don’t take his comments about the orders of magnitude reduction in code size to mean orders of magnitude reduction in required skill. I think this is the reason model-driven development is not mainstream. The stream is full of programmers that could never even develop the skills necessary to use MDD. Humbly, I know that I’m still a wannabe.

which was contested by H.S. Lahman

I have to disagree (somewhat) with this assessment. Yes, there is a substantial learning curve and OOA models need to be developed much more rigorously than they are in most shops today. Also, one could argue that the learning curve is essentially the same learning curve needed to learn to do OOA/D properly.

and later by Thomas Mercer-Hursh:

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?

I sympathize with Lahman’s and Thomas’ points (and share some of their puzzlement), but I do agree with Dan’s initial point: modeling can be harder than programming.

Separation of concerns? Not in the job description

The fact is that one can deliver software that was apparently appropriately built (from a QA/product owner/user point-of-view) and yet fail to fully understand the constraints and rules of the business domain the software is meant to serve.

Also, even if a developer does understand the business requirements at the time the solution is originally implemented, it is unfortunately very common that they will fail to encode the solution in a way that clearly expresses the intent so that it would be easy for other developers (or the author at a later time) to correlate the code to business requirements (as proposed by Domain Driven Design). That leads to software that is very hard to maintain, because it is hard to understand, or hard to change without breaking things. Model-driven development is a great approach for proper separation of concerns when building software (the greatest, if you ask me). However, as sad as that is, proper separation of concerns is not a must-have trait for delivering “appropriate” software (from a narrow, external, immediate standpoint). Ergo, one can build software without modeling, even implicitly.

I don’t think those things happen because developers are sociopaths. I think properly understanding and representing the concerns of a business domain when building software is a very desirable skill (I would say critical), but realistically not all that common in software developers. But how can hordes of arguably proficient programmers get away without such skill?

Delivering software the traditional (programming-centric) way often involves carefully patching together a mess of code, configuration and some voodoo to address a complex set of functional and non-functional requirements that works at the time of observation (a castle of cards is an obvious image here). Building software that way makes it too easy for one to be overwhelmed by all the minutia imposed by each technology and the complexity of making them work together and lose track of the high level goals one is trying to achieve – let alone consciously represent and communicate.


So even though I fully agree with the sentiment that proper programming requires a good deal of modeling skills, I do think it is indeed possible to deliver apparently working software (from an external point of view) without consciously doing any proper modeling. If you stick to the externally-facing aspects of software development, all that is valued is time to deliver, correctness, performance, and use of some set of technologies. Unfortunately that is all that is required for most development positions. Easy of maintenance via proper separation of concerns is nowhere in that list. And model-driven development is essentially an approach for separation of concerns on steroids.

What do you think?

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

12 thoughts on “How can modeling be harder than programming?

  1. Eric Rizzo

    February 11, 2013 at 12:41pm

    You are absolutely correct. I’ve seen it time and time again, including on the current project I am consulting on. The delivery of “functionally acceptable” software is almost orthogonal to properly designing (modeling, layering, architecting, future-proofing, etc) that software. Not completely orthogonal, but nearly so; especially when junior and/or poorly-managed developers are involved. Modeling *is* harder, I think because it leaves less room for ugliness. Or maybe it’s just that modeling a system is still a territory reserved for the architects and more experienced developers of the world. Who knows, but the fact remains that there is TONS of code delivered that has inconsistent, incomplete, or totally absent models behind it.

    • rafael.chaves

      February 11, 2013 at 2:10pm

      @Eric Love this bit, really a synthesis of this post:

      Modeling *is* harder, I think because it leaves less room for ugliness.

  2. Lee Riemenschneider

    February 11, 2013 at 1:55pm

    Here’s an interesting thing to ponder. Why is it that software seems to be the only engineering discipline where a prototype is an implementation rather than a model?

    • rafael.chaves

      February 11, 2013 at 2:09pm

      @Lee Exactly – were modeling more widespread, that would probably not be the case.

  3. Ant

    February 13, 2013 at 2:30am

    I model more than most people I work with but have always dreamed of a simpler set of rules than UML. Most people don’t model because they perceive the time as wasted as there is no deliverable. I have often offered to work with UML committees to define a ‘UML light’ but they insist that it is all necessary.

  4. rafael.chaves

    February 13, 2013 at 9:16am

    @Ant I think people will only see the value of modeling if the model directly affects the deliverable. So, in that sense, a lighter UML won’t help (it will help if you use models for communication only, but that is a very narrow approach to modeling). I would hope for a more modular language though, where you can bring in the feature sets you want depending on the application and the mode of UML you are using.

  5. Dan George

    February 14, 2013 at 10:12am

    @Lee, the separation between prototype and product exists in other disciplines because the difference in cost of production. In software, the cost of replicating and distributing a prototype is minimal. Not so for the material world.

    @Ant, the more I use the UML, the more I appreciate it (not the same as “like it”). EUML reduces the vocabulary to a very practical and minimal set. H.S. Lahman recommends ignoring the OMG spec but I disagree. It is so complete that you really can say what you mean and mean what you say. The deeper my understanding of the language, the more confident I get with my specifications that use it.

    Understanding the (a) language is necessary but no sufficient. One must also develop skills for declaring rules and specifying how objects change state such that the rules are met. Most “developers” are over-skilled at the dynamic part and nearly unaware of the rules part.

  6. Dan George

    February 14, 2013 at 10:19am

    Regarding the “ugliness” exposed by modeling, I think this is what can lead us out onto thin ice. I constantly catch myself over-modeling. The thin-ice idea is that I pursue beauty while creating more and more model that may or may not be supported by ancillary domains. I can end up creating an awesome model that isn’t realizable because the requisite unrealized support domains are either impractical or just too numerous to develop within time limits.

    Knowing how far one can go onto the thin ice is yet another skill a modeler needs that a non-modeler would never even think about.

  7. Remy

    March 7, 2013 at 6:01am

    As any tool, models should be made on purpose. As the article points out, the purpose is the separation of concerns. So, when is that useful ? Essentially it’s when
    concerns overlap and models are needed to manage shared contents: business logic, system functionalities, or technical implementations.
    As a corollary, a small experimented team working on a self contained application can do without models.

  8. rafael.chaves

    March 19, 2013 at 12:29am

    Hi Rémy,

    Apologies for the late response, almost missed your reply in the spam bucket.

    So, when is that useful ? Essentially it’s when concerns overlap and models are needed to manage shared contents: business logic, system functionalities, or technical implementations.

    How often does that happen? Any time one builds any real software, from my experience.

    As a corollary, a small experimented team working on a self contained application can do without models.

    Any real software development involves juggling a bunch of cross-cutting concerns. Unless you are writing a program that has an unrealistically simple object model, doesn’t need to persist data in the DB, does not have a client API, doesn’t need security, authorization etc.

    Sure, any one can do without models, if “doing” means getting code to run on a computer. But we both know software is way more than that, and we can do so much better.

  9. Lee Riemenschneider

    March 19, 2013 at 4:49am

    @Dan Many of the popular SW development approaches work off the assumption that SW prototyping is cheap, but the actual data doesn’t support that hypothesis. (Semi-) Working code is a lot sexier than requirements analysis (identifying invariants, SOC, estimation, etc.), so code prototyping is an easier sell.
    @Ant Ever seen the Shlaer-Mellor notation? UML was made to please everyone, so it provides very little direction to the user.

Comments are closed.