I failed to convince my students about the benefits of code-generation

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

As part of my MDE course, I devoted four sessions (of around 3h each) to a code-generation exercise. The goal was to model a simple CRUD-based web application and then use a professional model-driven development tool to automatically generate and deploy the application without writing a single line of code.

I thought this was the perfect example to show them the wonders of code-generation and, even more, use this as a bait to turn them into strong advocates of model-driven engineering in general. Well, based on the responses to a short survey I asked them to answer at the end of the exercise, I failed. In fact, I also failed last year, with a different tool. So it may be me that I’m not good as a teacher (luckily for my students and myself, my teaching days with undergrads are over) or that MDD tools in general are not yet good enough. Probably a combination of the two.

Anyway, let’s take a closer look at what the (29) students said after their first experience with a code-generation tool. But before some things to consider before jumping to fast to conclusions:

  • Note that the survey was mandatory and not anonymous. I emphasized several times that the only thing I’d evaluate from the survey was that their reasons for (dis)liking the tool were well-argumented but, still, some students may have chosen to give a more positive review than what they really thought
  • This scenario (generation of a simple CRUD web application) should be the abc of code-generators since there was no complex dynamic behavior that would require any kind of behavioural model (state machines, pre/postconditions,…) so it was, IMHO, the best one to illustrate the benefits of MDD.
  • On the “cons” side, it’s true that students are not professional developers having to build the same kind of applications again and again. We already know that MDD pays off in the mid-term so they lack that long-term perspective when evaluating the experience

Q1 – How would you mark the experience of using the code-generation tool?

(5 – Very satisfactory, 1 – Totally unacceptable)

Code-generation experience - Q1

Among the most cited (negative) reasons we had: lots of installation problems (I had to let them work in pairs so make easier for them to have access to at least one machine were the tool was working smoothly), lack of optimization of the deployed application (quite noticeable for a small application like the one we were doing, probably more reasonable when we move to more complex ones), sudden crashes and corrupted projects, good for prototyping but unsure if the if the method scales, lack of documentation and difficult to customize the code.

There were also some (but fewer) positive comments like: I think this is the tendency of the future. but we always learn more from the cricisms 🙂

Q2 – If you were working in a software company, how likely is that you would choose to use some kind of code-generation tool in your next web development project ?

(5 – Totally sure , 1 – No way I’m doing that)

Code-generation practice Q2

Here a few mention a MDD tool could be used to generate the back-end part in web development project
and It can be a great help for database management or a quick and dirty generation for a prototype but that for the front-end part, I think it is a waste of time specially because they had the feeling they would need to end up modifying lots of the generated code in the end since since this kind of tool will never be as configurable than a HTML/JS project .

A couple of students also mentioned but for the kind of scenario they would find the tool useful (this back-end admin generator), a tool like Telosys (or for what matters, most programming frameworks nowadays) that can generate a simple scaffolding interface from only a database definition could be simpler to use. Clearly, MDD tools need to find the sweet spot between language expressivity and tool simplicity here.

Q3 – In your opinion, what would make MDD tools more useful and attractive to programmers?

This open question gave some good suggestions of some new features for this kind of tools, like:

  • Being able to build your pages by drag and drop
  • Ability to change the generated code in a maner that would affect the model
  • Some common pattern already implemented by default (like login, CRUD tasks, etc…)
  • Easier to build multilanguage applications

plus some requests for non-functional aspects like documentation, better compatibility,… (result of the problems reported in the first question)


I think this comment from a student is the perfect summary of the situation:

The concept of generating code seems good in itself. However, I had so many problems with the tool I didn’t even think I was saving time. I also had the feeling the tool was lacking a lot of flexibility to really get the result you want/need.

that is, code-generation is not really the problem, the problem is that (after so many years) we haven’t been able to build usable (usable for an end-user company not to be only useful when used in-house by expert consultants) to produce software for tools that truly deliver on the promises we make.

As a side note, several students angrily complained about a remark I did in class on code-generation tools replacing programmers in the development of many kinds of business applications. Regardless what you think about code-generation, we must be doing something wrong if our students see themselves as mainly future programmers (and not engineers, architects, …).

I’ve to say that this is my second failure with code-generation. Before I also failed trying to sell online code-generation services so maybe it’s just that I’m not the man for the job 🙂 .

Update: You may want to also take a look at the reddit discussion on the topic

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
  1. Jean-Baptiste Guillois
    • Ben Alabaster
      • Lee Riemenschneider
        • Ben Alabaster
    • foo
      • Lee Riemenschneider
  2. Lee Riemenschneider
    • Jordi Cabot
  3. John H Morris
  4. Juha-Pekka Tolvanen
    • Jordi Cabot
      • Juha-Pekka Tolvanen
  5. Steven Kelly
    • Andreas Leue
  6. Peter Bindels
    • Lee Riemenschneider
  7. Antonio Carrasco Valero
    • Juha-Pekka Tolvanen
  8. Antonio Carrasco Valero
  9. Gilligan
    • Jordi Cabot
    • Antonio Carrasco Valero
      • Andreas Leue
  10. Det
    • Lee Riemenschneider
    • Andreas Leue
  11. Joao Santos
    • Andreas Leue
  12. Desfray
    • Marco Brambilla
  13. name
  14. Dan George
  15. Bahman Zamani, PhD
    • Marco Brambilla
  16. Andreas Leue
  17. cliveb
  18. Steven Kelly
    • cliveb


Your email address will not be published. Required fields are marked *