Tuesday, May 12, 2009

Why is RCP, EMF, p2, databinding... so hard to learn?

There are some interesting discussions on my recent blog entry on "How to explain EMF?". The debate is between those who find it hard to learn EMF and those who have a hard time seeing the difficulty. I think there is a general pattern behind this debate. The same arguments could be made for almost any non trivial technology/framework inside and outside eclipse (EMF, RCP, p2, databinding, [your "favorite" hard to learn technology],...).

Why do many people really suffer form the steep learning curve and others master the same technology easily?

I think we have to step back for a moment from any concrete technology and we should to look at how the technology gets created and how learning and applying of the technology works.

The creators of the technology/framework have a deep knowledge in the particular domain the framework solves. They have created several software systems where they saw some reoccurring patterns. They realize by putting the common parts into a framework they can dramatically increase their productivity, because the work is then reduced to assemble the pieces and write some "glue code" (in some sense they create a kind of domain specific language for that problem). As long as the creator(s) of the abstraction are the only users of the system, there is no real problem and they can show dramatic increase of productivity, because they can focus on the business relevant part of the system.

Now comes the next phase, where others adopt the technology. Those early adopters are usually people with a similar experience background as the original authors of the framework. They have typically written such systems by hand or created their own framework and they see the value of the technology. For them, learning the system is almost effortless because they understand the underlying problems and the solution provided by the cool technology. Good candidates of successful adopters are typically consultants using the technology in multiple projects. They report impressive increase of productivity. Let's call them expert users.

Now another category of users, the normal users wants to use the technology. They see the impressive results created by the expert users. The expert users tell them how effortless this is and how quickly you can create solutions.This is where the problem starts! The expert users understood the problem before they started, they understand the solution in depth and they reapply the technology to many projects. The normal users typically have a single project where they want to apply the technology. They might have a vague understanding that the new technology fits to their problem. The "documentation" build from expert users for expert users make no sense, because there is a lot of background knowledge and experience missing. Normal users have to put a lot of effort into learning and understanding a complicated system just to apply it once.

If the normal user manages to use the technology to solve his problem, his solution is often "suboptimal", because he might be happy to have found just one solution. The expert would see that it is by far not the best possible solution, because he has a much deeper understanding of the solution space. OTOH, the normal user might have a much better understanding of his specific problem domain and the expert might propose a bad solution, because his limited understanding of the problem domain.

Let me give you an analogy: Some weeks ago, my mother told me that she has a serious problem, because her old typewriter broke. She explained me how they do their tax-declaration: my father hand-writes tables with income and expenses and my mother types them with the typewriter. Well, they have a computer (which they use to read email and browsing). The solution is clear: a spreadsheet is all the technology they need to optimize the process. Me "the expert", could just tell them that they can be much more productive by using this "new and cool" technology. All, they'd have to do is to enter the numbers directly into a spreadsheet and with a few more mouse-clicks and a bit of excel programming he would even get some cool graphics and analysis.... Do you think I did that? No way. They are in their mid 70ies, they have done it "their way" all their life. How steep would their learning curve be? Does that mean they are stupid? My father is extremely good with his hand written tables, he uses colors and creates cool graphs by hand. He has an extremely good understanding of the money flow. He even knows exactly how much money they spend on me and my brothers from our birth to now. I wish I would have 10% of his knowledge on where my money flows.

In this example we see very well the difference between "expert users" and "normal users" of the technology. This technology would work really well for me and would not work at all for my parents. And even if I would try to teach them, I would have to use a very different language to explain it to them than I would use it explaining it to you. I would have to explain them what a spreadsheet is and so on. Then I could ask them if they prefer open-office or Microsoft office. Because they have absolutely no idea, even this simple this choice would stress them a lot.... Once they would start with an empty spreadsheet, there would be so much choices and decisions to make that they would be totally paralyzed. Would examples or documentation help? Well somehow, if an example does exactly what they want to do, but then it is almost the solution. Does that mean that spreadsheets are complicated technology? Well, it depends on your background. I think it would be more efficient for me to help them doing their tax declaration and prepare a spreadsheet and every time they do it, sit with them and help them. But I think the way they do it is OK for them, all I need to do is to fix my mothers typewriter.... If they were young and they had a lot of numbers for their tax declaration, it would make sense for them to learn the technology....

OK, I stressed this example enough... What does this mean for the "complicated" technologies around eclipse?

  • There is a big danger that a great technology gets a "bad reputation", just because "normal users" want to apply it and they find it the technology incredibly hard to learn and to apply.
  • As expert user, you can cause a lot of damage it you tell some unexperienced users to use a technology without guiding them. And in some cases it might be better to tell them not to use the technology if they are not "ready". For you it might be the right choice, for them it would cause disasters at all levels.
  • Learning "complicated" technologies might not be worth the effort if you want to apply it once.
  • Ask yourself if it is more efficient to hire an expert than to learn the technology. Especially if you want to apply the technology only once in a relatively simple way. In this case the expert can be 10-100 times more efficient than you.
  • If you are a normal user and you still want to learn the technology, be prepared that is takes time and it is a painful process. In order to make educated decisions you have to become at least "Competent" (see the Dreyfus model of skill acquisition) or needs "Conscious competence" (see Four stages of competence).
  • Maybe expert user and normal user should team up to write documentation and create example. For experts it is often very difficult to understand the problems of normal users and for normal users it is impossible to come up with good examples and documentation.

This post is a bit longer than my normal posts and I kept is as draft for a while but I decided to post it. It is a bit like with complicated technology: you can't explain it in two sentences ;-)....


  1. I really like the idea of combining normal and advanced users in the documentation process. A requirements engineering that I worked with would always suggest using a smart ignoramus, that is a really smart person, ignorant of the domain.

    However, in practice this is also very hard. I have tried to be that normal user, but as you start down the path of writing documentation, you soon learn why things were done a certain way, and eventually you too become an expert users.

  2. I think it is important for the expert user who want to build a new system to keep the normal user's needs at the forefront of everything they build. After all, if the normal user can not get the great technology to work then it is wasted technology. In my experience EMF is like that. All I need is a simple way to define Objects with attributes and get a code generator to build out simple classes with event notification, automatically, embedded in the setter methods. I like EMF's use of annotation in the comments to selectively disable code generation. I've never found the code for UI as useful.

    Thanks for the posting.

  3. You made some good points, but I have to add some comments ;)
    If a software is too hard to learn for normal users it is not a good product and has to get a bad reputation. Easy adoption is an important requirement for APIs and frameworks its purpose is reuse.
    As an "expert user", although I think the definition is not good, has to have ability to explain the technology in a way the "normal user" understands it, that's a point where the expert seperats hisself from the normal.
    Your example is not well chosen. For a software developer learning new and complex technology is a MUST HAVE. You cannot build software products from scratch, you always have to use any third-party-technology. So the question is, where does the "normal" ends and where does the "expert" starts?
    Complicated technology is no good technology and not worth to use it, I guess you mixed that with "complex".

  4. You have explained a complex problem in a simple way.

    I feel that the documentation of eclipse technologies should be written the same way.

    I learnt GEF after putting lot of hard work. In reality GEF is an easy to learn framework. But the existing documentation slowed the learning process. I tried to learn BIRT, but failed.

    Most of the time what happens is, the technical engineers may not be good explainers;but the responsibility to write the documentation is given to them.

    Once the technical lead of a technology/framework is sensible enough to give responsibilities based on individual strengths, may be this issue can be solved.

  5. I think that Eclipse and these projects are just fantastic but there is a misunderstanding.

    Do you know that to train a good EMF developer you need more than 18 full time month ? I agree that this investment is very good but only if your job is 100% focused on modeling as research engineer.
    The misunderstanding is coming from the eclipse foundation which is trying to promote the use of frameworks among developers and not to promote the use of plugins such as EclipseUML which are built on the top of open standards such as EMF.
    Users are now convinced that if you want to model you need to directly use EMF, and don't buy anymore software from Eclipse plugin vendors. As a plugin vendor we invest now less into the Eclipse technologies and nobody is happy. Users needs incredible time just to create small applications and ISV are not anymore interested by this non profitable market.

    I don't know what to say except that if you want free technology then users should accept to pay the personal learning curve price. If you want to be immediately efficient then you have to pay for professional tools vendor which have invested in such technologies.

  6. So many in this discussion seem to claim that they:

    1. Had a very hard time to understand the benefits and the functioning of modeling or EMF.

    2. Finally mastered all this pain and are what Michael calls expert users now.

    Who of you can explain what exactly made it so hard?I think we urgently need this specific kind of experience report in order to make things better. (I don't believe that the goal will be to make modeling or EMF better, but the marketing and documentation must certainly be enhanced).

  7. What makes EMF so hard?? Part of the difficulty in answering that question is that it depends on each individual's background.

    When I started learning EMF, I was starting from scratch. I was a embedded driver programmer, writing software for hardware. I knew nothing about eclipse and modeling, and only a very limited knowledge about things like design patterns and such. This of course made my learning curve extremely difficult.

    I don't think I'm a good person to ask that question. But with that said, when you want to improve documentation, you have to make assumptions about the audience's background, and at some point you have to draw a line.

    It comes down to the fact that EMF is designed to be a general purpose solution to solve a problem domain that is very difficult to generalize.

    If you are only going to use EMF on a single project, you are wasting your time. And even if you are using it on a small number of projects, you are probably still wasting your time.

    EMF is a career choice.

    EMF is not a project choice.

  8. This is a very insightful blog. I often emphasize the fact that simplicity is in the eye of the beholder. When first I learned Java's generics I was horrified by the complexity, and I have a Ph.D. that focused on programming language design, but now it seems straight forward. All too often I read comments about EMF and I think, those very same comments apply to Java, or any number of other technologies, so I like the fact that your blog is about the more general aspect of complexity because this issue is not unique to EMF. For example, if you are going to do only one project with Java, is learning all of Java a good investment? I doubt it because Java too is a career choice...

  9. EMF is a baby compared to GMF. ;-)

    From my experience:

    When you come to the web page of EMF, M2T, M2M and similar projects you don't know what you're looking at. What's the purpose of EMF? Why do I need it? Why does oAW use it? What's the general idea behind it?
    How these projects relate to each other?

    Another problem with Eclipse projects is content management. It seems to me that projects constantly split and move from one area to another.

    Not to mention GMF stuff. I haven't figured it out yet, but this is the only project that has a diagram explaining necessary steps in order to create editor.

    In order to get something from these projects you need to invest a lot of time or you need someone to coach you.

  10. Hi! Your blog is simply super. you have create a differentiate. Thanks for the sharing this website. it is very useful professional knowledge. Great idea you know about company background.
    Customized application development

  11. I have been developing commercial eclipse-based products for 6 years and I generally avoid using technologies like EMF and GMF because of their steep learning curve and because after I leave someone less experienced will have to maintain the application. I lean toward the KISS (Keep-It-Simple- Stupid) design pattern.

  12. Hello Shawn,

    I agree that EMF and GMF will take initial time to learn.

    EMF gives lot of re-usable features which you can make use in your projects. Otherwise, you are re-inventing the wheel always.

    In software development, the key to success in future is the ability to learn and execute projects faster and efficiently. EMF and GMF are frameworks which helps for that.