The reasons why modeling is doomed to failure are seemingly endless.
- The learning curve is too steep. Only someone with a Ph.D. can actually understand UML, or at least do a good job pretending.
- When I hear the word "meta model" it turns me cold; talk of "meta meta models" makes me want to cry.
- Modeling's complexity will only distract me from solving the problem at hand thereby slowing me down.
- Modeling is totally redundant. Java already has a reflective object model, so why would I need another one? Learning one general purpose programming language is more than enough of a challenge and should be more than sufficient. They're Turing complete after all, so it's provably true.
- Modeling is simply too restrictive thereby limiting my creative abilities.
- It's patently ridiculous to believe that modeling will be sufficient to generate my whole application without need for writing actual code.
- Generated code is of poor quality, performs poorly, and is difficult to understand and maintain. I can do it much better myself by hand.
- I don't like all those stupid diagrams. They just don't scale. A textual representation is far more manageable. I simply don't need a graphical rendering of my code.
- Domain specific languages will create a Tower of Babel rife with formalisms that only the original developer understands.
- XML Metadata Interchange (XMI) is unspeakably horrible. I want nothing to do with it.
- Modeling is just a ploy to ensure that I'll need to buy expensive tools. Tool vendors tend to support their tools for only a few years before changing them all around as part of some new marketing campaign, thereby risking my long term investment.
- I won't be able to do agile iterative development but rather will be stuck with an onerous formal waterfall process.
- My project isn't big enough to need all that formal modeling overhead.
- If modeling really did work well, I might as well out source my high tech job to the developing world.
I'll explain why at various conferences this fall, including MDSD and perhaps JAX and ESE. Today is the last day for ESE submissions, so don't delay!
Posts
9 comments:
Hey Ed, leave UML already, and come and try the BPMN modeler! :)
OK, that was a shameless plug, although the current goal of the modeler is to be based on EMF and at the same time focus on the user experience.
If you want to convince me that modeling makes things easier, then you need to do a better job of explaining it. On three separate occasions, I've attempted to figure out EMF and to try and apply it to work. I still don't understand what its purpose is. From what I have picked up, EMF can't do anything for you until you write the classes that make up your model. This is completely backwards from what I would expect.
The model that comes out of the process allows you to create logical relationships between model objects. Woopee! That has zero value in the applications that I'm working on.
The disconnect between evangelists like you and developers like myself demonstrates the need for better communication explaining how the whole process works and why it is worthwhile.
@Anonymous: you do not need to write / generate any classes to use EMF. Instead you can use Dynamic EMF, which enabled you to use the reflective EMF editor to create models based on your metamodel (aka a model for your model).
@Ed: instead of preparing talks and demos for conferences, we should consider doing a "reverse talk": give the mike to the audience and have them ask questions and and let the presenters answer those questions.
Anonymous,
It's good to keep in mind that it's a competitive world. Those who figure out how to compete better will find they are in a position of advantage. I'm more than content simply to present people with food for thought and then let them make up their own minds.
EMF really isn't all that hard to figure out. Many thousands of people have done just that. It seems to me that even with Java you can't do much of anything until you write your classes. I don't know if that's backwards. I always thought that was forwards...
Peter,
I always thought I was just someone who built really cool technology that other people used to save themselves a great deal of time and effort. The technology pretty much always seemed to speak for it self. After all, large corporations build huge product stacks on top of it. Mind you, a great many people had endless complaints about it too. The interesting thing is that when examined closely, most complaints aren't associated constructive thinking.
I'm more than ready to assimilate good ideas into the framework. Occasionally I rant a little just to see what pops up. Failing the arrival of good new ideas, I'm always interested to see if someone comes up with a new complaint that's not already on my list of "been there heard that."
What you are missing is that developing software is about being flexible and doing what works for your team in your situation.
Modeling is just a way of communicating ideas with others so that they don't have to read code, and that they can try to understand the parts of the system as a whole before you start coding.
Sorry, generating code from models does not save me that much time and I'd rather sit there and write the code out myself referring to the model because it gives me more time to reflect on what I'm doing, as opposed to having some "framework" produce a "model" and toss it over the fence. Then if the developers implement the model and something comes up, who cares? We'll just regen the code!
I have smaller projects. I model using visual tools, print the models off and put them on a wall and then draw on them. Every once in a while I sync the drawing on the wall, the code and diagram file.
Long live getting work done!
Chris,
When I presented my talk at NASA, I pointed out several times that it's best to use the right tool for the right job. Modeling is not intended to replace "real programming" it's intended to complement it. Anyone who claims it to be a panacea is making the kinds of claims that tend to give modeling a bad name.
Modeling isn't just a way to communicate ideas to others, it's a way to communicate high level ideas period. The expression of those ideas ought to be directly consumable by a computer so that the designer you can move on quickly to reflecting on the results of the design and its use in the rest of the application, rather than on the predictable and mind numbing details of named interfaces with paired getters and setters, corresponding implementation classes to implement those interfaces, a factory to create instances, serialization code, and so on.
Surely as programmers we can learn to automate the routine aspects of our work. I.e., capture best practices and design patterns so we can more easily orchestrate ever larger and more complex designs. Long live getting the work done with better quality and having more time to focus on the interesting tasks rather than the tedious ones.
Anything which is not simple enough is doomed except for may be grady booch.
You dont need to be a rocket scientist to be a programmer however if your tools are designed for rocket scientist then you are either selling software to enterprise customers (read executives) or working for a big company with million dollars to spare.
Chris,
I agree though it's also the case that simplicity is in the eye of the beholder. If you look at
all the web services standards or the
Java Language Specification
I'm sure no one will argue these are simple. I also doubt anyone will argue they are doomed to failure as a result.
Powerful things tend toward complexity and powerful things are generally what people really want. They only want simple when they start, but once they've learned the simple things, they won't be happy with just that.
Tools that are designed primarily with an eye to executive appeal seem unfortunately all too prevalent. As with all the misconceptions I spelled out, the fact that they all come so close to hitting the nail of truth squarely on the head is what make them seem so compelling a counter argument. Misinformation is always most effective when it has the ring of truth.
"I agree though it's also the case that simplicity is in the eye of the beholder. "
This seems to approach the heart of the problem. Modeling is one way of representing something. However, not everyone is able to understand the model or Modeling itself. This makes things hard. Modelers "get" the model because they "get" the process. Developers who don't "get" modeling don't "get" the model. Ed included some pictures with with his post. To me, One sort of looks like a frog, the other sort of looks like an animated freight train. Ed sees a frog and a witch. We agree on one interpretation but not on the other.
Perhaps a better example would be those stereoscopic dot pictures where you have to stare beyond the picture to see a 3d image. Some people can see the rocket ship taking off, others give them selves a headache staring at the picture. Once you figure out how to look at the picture, it becomes easy and the headaches go away.
I've been a software developer for 25 years. Through out that time, I've had a number of eureka moments where the light went on in my head and I finally got something that I had a hard time understanding. Once the light went on, a concept that was previously hard became easy. I haven't had my modeling eureka moment yet.
I believe that this is what I meant when I talked about the disconnect between evangelists and developers in my initial post. It's a difficult problem to approach. Like with the pictures, you can explain the process but in the end, the person viewing the picture has to see it for themselves.
Post a Comment