Generating a MEAN-style web application from models (T plus 1 days)

This is the last installment to a series started about two weeks ago. If you remember, I set off to build a code generator that could produce 100% of the code for a business application targeting the MEAN (for Mongo, Express, Node.js and Angular) stack. I am writing this a day after the presentation took place.

So, the big day finally arrived. Unfortunately, the presentation was not one of my best. If my delivery was not that great, to make matters worse, turns out my idea of exposing MDD (with Javascript as target platform) to a crowd seeking wisdom on Javascript didn’t work very well, people didn’t seem be interested in modeling and code generation at all. Something to take into account in the future. Anyways, the slides (in Portuguese) appear below this post.

Also, the code generator was not complete (was anyone else surprised?), so I couldn’t show code running for many features, and instead had to show the generated code (that looked almost right but not quite there yet). I guess that contributed to a less interesting presentation.

On the bright side, a lot of progress on the code generator was made. Take a look at the latest state of the generated code. I am quite proud of what is there now. But there is still more progress to be made until at least the sample applications I have all translate to feature complete and correct MEAN applications.

You will hear more about that here in the near future. Stay tuned.

EmailFacebookLinkedInGoogle+Twitter

7 thoughts on “Generating a MEAN-style web application from models (T plus 1 days)

  1. Jürgen Mutschall

    October 20, 2014 at 7:30am

    Hi,

    with this fresh impressions from your presentation, I would like to ask you a serious question: What ist the minimum critical mass to get hardcore developers exited for MDD/MDSD/MDE?

    IMHO currently only the “my grandma can program, too” solutions are successful, see MENDIX or ICENETICS.

    My personal list of required features:
    1. Adress the right audiance: the big money projects not the small amateur web developers.
    2. A MDD solution must show somethng that cannot be done manually, even with big, big effort or clever hacks, scripting, templates etc.
    3. It has to be a “production ready” solution.

    What do you think?

    Regards,

    Juergen

  2. Rafael Chaves

    October 20, 2014 at 10:08am

    Hi Jürgen, thanks for your comment.

    What ist the minimum critical mass to get hardcore developers excited for MDD/MDSD/MDE?

    That is the money question, isn’t it? My hunch is it is a combination of full code generation with multiple target platform support (with relevant target platforms).

    Full code generation (as opposed to partial code generation) is a requirement for MDD to have an impact – otherwise, developers will need to fallback to hand-coding the interesting and it is just an awkward scaffolding mechanism, and with no significant benefits for maintenance.

    IMHO currently only the “my grandma can program, too” solutions are successful, see MENDIX or ICINETIC.

    Mendix targets a different market I am interested in. Now, on “hard-core developers”: I am not interested in those folks either. 3GLs already serve them well.

    I am interested in people trying to productively delivering high business value with good quality. More specifically architects and application developers building and maintaining business applications.

    On your list of required features:

    1. Adress the right audiance: the big money projects not the small amateur web developers.

    What are the key differences between them? (for strictly technical reasons, i.e. business reasons aside). MEAN, JavaEE, etc are just target platforms with their particular idiosyncrasies, what can be done in one can always be done on the other etc.

    2. A MDD solution must show somethng that cannot be done manually, even with big, big effort or clever hacks, scripting, templates etc.

    Sorry, I don’t get what you mean by “cannot be done manually”. MDD is all about working at the right level of abstraction, not about what is achievable, right? Anything that can be done with MDD can done manually, just as anything that can be done with Java or Haskell can be done with Assembly. Or are you thinking of constraint solving etc? But then, once you integrate a constraint solver in your app, that becomes available no matter what level of abstraction you are at.

    3. It has to be a “production ready” solution.

    Agreed, but that goes without saying, right?

    Rafael

  3. Mike Finn

    October 20, 2014 at 8:05pm

    Hi Rafael & Jüergen,

    I agree full code generation and multiple target platform support is a must. This should include the ability to configure the application’s architecture, especially to accommodate multi-core systems.

    If by “hard-core developers” you mean programmers then I agree. Don’t bother selling MDD to them because it’s our purpose to replace them. We must aim higher up the food-chain. Our target market must be Business Architects, Project Managers and Enterprise Architects and higher.

    Something that cannot be done manually (not feasible for cost or skill reasons) is future proofing. Matrix embodies the idea of one model for the application (analysis model) and another for the application’s architecture (design model) which are developed independently of each other.

    So if a new language or database comes along well after the application model describing the business rules have been written, it just becomes simple (or not so simple) case of creating another design model.

    Regards,
    Mike

  4. Rafael Chaves

    October 20, 2014 at 8:17pm

    Thanks for joining the conversation, Mike. Personally, on “hard-core developers”, I was not thinking of all programmers, but those that are inclined to system level stuff, frameworks, tooling etc. Those don’t need to raise the level of abstraction (because 3GLs are enough – or sometimes even too abstract – for system level software), and I would disagree that MDD would make this group obsolete.

    Instead, I’d much rather affect the work of “business application developers” – not by making them obsolete, but by providing them with better tools that would allow them to focus on the part of their job that is high value (the crafting of business application information model and rules, or in Eric Evans’ words, “domain knowledge crunching”) by completely removing the aspect of their work that is low value (but paradoxically very time-consuming and error-prone): the mind-numbing mapping of their conceptual solution for some problem domain to the idiosyncrasies of the target platform of the day.

  5. Mike Finn

    October 21, 2014 at 9:28pm

    Rafael,

    On “hard-core developers”, I was responding to Jüergen’s version. That is, the vast majority of programmers who just program business IT applications in common languages.

    On “business application developers”, by completely removing the aspect of their work that is low value, they in effect, convert to analysts and I suspect the percentage that would be enthusiastic would be in single figures.

    • Rafael Chaves

      October 21, 2014 at 10:11pm

      they in effect, convert to analysts and I suspect the percentage that would be enthusiastic would be in single figures.

      Your estimate could be right, Mike. The hopeful in me would like to believe it is more than that. Either way, if MDD finally succeeds and ends up getting the acceptance it deserves, those that would rather preserve the current status quo may become unable to compete with their more effective peers, and so might face a choice between settling into the new way of building business software, or moving on to work that is more rewarding to them, such as system-level software, or even MDD tooling. Either way, everybody wins!

Comments are closed.