How to make MDSD more attractive to the "mere developer mortal"?

Replies to This Discussion

Permalink Reply by Jorge Ubeda on March 17, 2009 at 22:58

Completely agree with Juha. For all MDD tools is my feel that a great resistence is the usual reaction for the average developer: distrust in the code generation, underestimate of model based design. But even managers do not ever trust in MDD: in this case, other arguments: small companies undertaking MDD, immaturity, untrust in project continuity, fear for trainning time required...I see this aspect more difficult to face, and more important to solve.

• ▶ Reply

Permalink Reply by Michael Osmond on March 18, 2009 at 3:53

My first reaction to the question is the problem is right there - "mere developer mortal", do we have to be more than mere developer mortals to get this?

However, I will try a left field answer: how about we stop paying people by lines of code, or hours of effort, and pay them for value of systems delivered? Assuming that you can deliver a system of equal or better value for less effort if you use MDSD, then shouldn't paying more for less make it attractive?

• ▶ Reply

Permalink Reply by Rui Curado on March 18, 2009 at 9:33

I agree that people are more productive if they work for objectives instead of working for just the time spent on it.

However I don't see how easily we could value "value". And mere developer mortals would still have to need/want to use MDSD...

• ▶ Reply

Permalink Reply by Jon Hurwitz on March 19, 2009 at 13:29

Yes, most developers are paid by time spent, lines of code, etc., and have no financial incentive to become more productive. And nor have management. Why champion a new method when the old one delivers. If you fail your job is at risk, if you succeed you are just increasing future expectations. On the other hand, asking developers to work fixed price is impractical. Managing a fixed price contract can be a nightmare for the experienced project manager and the average developer hasn't enough influence on his/her area to prevent function creep. Project bonuses might help if structured correctly.

I think we need a top-down, business-driven initiative. Only by defining value in terms of the overall business are we likely to get anywhere. Even though many methodologies require an initial business case to be written in terms of financial value, I see it far too rarely in practice. And it never gets passed on to the developer.

• ▶ Reply

Permalink Reply by Rui Curado on March 20, 2009 at 12:50

"Do you think that having different stages of MDD generating code on demand and not immediately generating the entire project structure is the answer to the MDD adoption by the developer community and the management ?"

I think that one of the reasons on MDD adoption resistance it its current setup: Complex MDD architectures (UML/EMF/Xtext/XMI,etc), tool chains (lack of "one-stop shop" environments), and the pursuit of the "perfect solution" (sometimes too abstract for the "mere mortal").

It's easy to "sell" MS Visual Studio: Integrated, single-environment product. It's harder to sell a MDSD solution relying on a tool chain using a complex architecture. Of course, I am not saying MS VS is a good MDSD tool, just showing how a product/idea can be easily demonstrated.

My bet goes to a combination of a simple, evolutive modeling architecture and an IDE. That's what I am working on.

• ▶ Reply

Permalink Reply by Vitaliy Fedorchenko on April 3, 2009 at 6:03

I guess you're right - main reason is "imaginary" MDD complexity (I know a lot of developers that really believe in MDD==MDA and knowledge of UML/MOF/QVT is required).
I think that domain-specific MDD (on contrary to general-purpose modeling infrastructure like MDA) is much more close to "mortal developer". And I know that native, easy-to-use and powerful infrastructure can be organized without much efforts (I'm talking about NReco i've introduced in my blog, as a good sample of such "pragmatic" MDD infrastructure for .NET platform):
- actually "mortal developer" can start using it only with knowledge of XML/XSL
- I suppose using VS 2008 (free Express edition is ok) for editing XML models (it supports very useful custom intellisense based on XML Schema). From my experience this is IDEAL tool for editing XML models (all 'visual editors' I've tried absolutely unusable for models with >100 elements).
- special transformation tool (that supports incremental and 'on-fly' transformations) enables "rapid" MDD development, when developer can change the model and see changes in application in few seconds. This is really important for "mortal developers".
- special "semantic search" tool that uses special knowledge base about models, schemas and transformations. It should help "mortal developer" to keep mental health in real development.

• ▶ Reply

Permalink Reply by Juha-Pekka Tolvanen on April 1, 2009 at 15:16

I should obviously record what I said ;-) but based on my experience developers’ attitudes to modeling and code generation is much better after:
1) they see how it works in their area (like being able to read and understand the generated code)
2) they realize being able to influence and even control the way of modeling and generating their code.

It is so easy to say that it does not work if you have never actually tried - or have just used a UML tool to generate skeletons and then disappointed. That brings to point 2). Many developers have bad experiences on using modeling and code generators tools (CASE and UML tools) that provided fixed modeling languages and generators. I believe that developers’ want to be on driver’s seat.

My answer to Rui's question is to publish industrial cases.

• ▶ Reply

Permalink Reply by Lothar Behrens on April 2, 2009 at 12:30

I would express my thinking, my experience I have made and suggest a tender spot how to achieve a boost for a comunity, I think is very big. My english is not perfect, so sorry about that :-)

First, I agree, that it is difficult to enter the space of MDSD.

In my opinion, as a developer with basic UML and profile knowledge, it was many times too complex to get started with eclipse and oAW. Mostly because it cost too much time to just try it out. I had to ask in the comunity how to get the uml2ecore sample running, just because my last reading of the getting started documents of oAW was to much in the past :-)

So if I have these difficulties to get started, why should a small company investigate time to just try it out. Say, if I am the CEO of a small company and see the need for an application to manage customers to get called actively before they call me for ordering, I would prefer to use Access to build up that simple application.

But then I am locked to it or it requires much cost to, say port it to Linux, for sample.

I have gained experience exactly in that issue. I begun with an Access application, because I didn't know about better solutions, or even the fact, that i am locked to Access.

Nowadays I know about this and I also know about the value of code generation and also how much could generated with just one click :-)

I would therefore suggest to start thinking about that point.

Q: Why didn't I knew about the possibilities?

A: I did not came to the idea that many parts of code could be generated.

A: In the IT administration, all must go fast. We were locked to use Microsoft products and therefore in the database field I used Access for simple solutions.

That was my experience some years ago. The simplest solution for a problem to get working software for it FAST was to use Access.

So in my opinion a case study around this topic should point to better solutions with minimal efford to achieve that.

The case study should compare creation of Access solutions and another solution based on a simple application for prototyping of the identical problem, but pointing to the possibilities to go further with code generation or bridging to more experienced methologies as oAW does with MDSD.

Also with a prototyper, you could point to use a more or less open XML format for the definition of the application - compared to Access. There are other tools that read access databases and may be a replacement. I heared about them, but don't know much about.

I think, if I could get knowledge about such a case study and I could simply try it out with a small application instead of eclipse - with a better solution in mind (than Access), but easy to try - I definitely would try that way.

If the IT administrators get knowledge about such technologies - starting with a simple application - it would be a big boost for MDSD. There are so much IT administrators in the world having the same problems.

We should attract those people, they then would tell about the possibilities to their boss and suggest doing more with that.

So we point out a tender spot for a big comunity (the administrators) and they will do the work for us :-)

As mentioned above I were in that problem. Struggling with serving the boss FAST, I searched for a solution. I programmed an application in Java to fasten up the creation of the application. The major point also was the always changing ideas from my boss to get implemented. Thus programming that manually was always dangerous, because with a new desicion from my boss I tend to trash the code into the bin.

The solution was a manually coded 'code generator' that based on configuration in a database for the forms the application has to serve. The code generator was a caching mechanism to achive faster application when the model get stable. The prototype programmed it self :-)

As this was a quick hack, how many other administrators or developers would do similar things?

The only point I do not know is where to place such a case study.

The application I wrote in Java now is reprogrammed with more knowledge about MDA and MDSD, so it follows the goal by supporting an open format (XML). The design is so much about dynamic in mind that the prototyper application it self is a prototype. BUT, it still looks like a simple CRUD application what makes it attractable for administrators to enter the space of MDSD.

When understanding DSL correctly, my DSL is the prototyper and the internal format are some tables that holds the models in the format of that DSL.

Currently the application is selfcontained (using Sqlite) thus it simply could tried out. I have several basic 'cartridges' as XSLT templates, thus the user could try out these cartridges and what is it about code generation, by simply generate the prototyper it self for a different target environment.

If the admins would look ahead, they simply could export the CRUD model and get an UML (XMI) model. (I still search for an error free representation in UML. Not all is possible)

About all my writing, what do you think about a CRUD like tool that seems to be an entrypoint in MDSD for the targeted audience (administrators/database administrators)?

The problem in one of my last company was exactly about creating an application that should be used for active customer 'call' to provide a service to the customer. 'Hey, they call me and indeed I have to order. My stock is nerly emty.'

There were exactly the problems:

CEO: When did we get the application?
Me: The software must be developed, that costs much time.

CEO: How much we could get in 4 weeks?
Me: Maybe only some basic functionality like as a prototype. You can't really use it.

CEO: That is bad and seems costly. I think we will keep using our Excel solution.
Me: Hmm. You really get trouble if the amount of data gets big. And all employees could do anything with it. And what is when there multible versions about the Excel document?

CEO: Hmm, yes. We have to pay for that. The downside of Excel costs more I think.

Today I could argue differently:

CEO: When did we get the application?
Me: We need to hold a meeting to scetch up a basic model ow what data should be kept in the database. Then I could generate a prototype.

CEO: Ohh cool. What did we could do with the prototype?
Me: Test the functionality by a small test team of staff involved in the proccess to serve the customer and do the calls.

CEO: Great. How fast the prototype will be as feld by the user?
Me: Little slower because the application is 'dynamically' created.

CEO: Hmm, what means dynamic. Could we quickly change something in the app?
Me: Yes, as it is a prototype.

CEO: So we get a running version with our needs very fast. What is then?
Me: There is the possibility to generate code, after we have decided in what language we would
generate in. Also there may some need to tweak the existing 'templates' that do the generation.

CEO: Cool. If we decided wrongly using C++, but need a web PHP application. Just do we replace the template?
Me: Yes. But mostly we do need some tweaking, as of your requirements in look and feel :-)

CEO: Ok, we will do that. It saves us a lot money. Where did you get these knowledge?
Me: There was a case study that lifted my eyebrows.

CEO: We will keep an eye to it. Please give me some contact data to get more information. I will setup a company wide meeting about this exiting methology for the stakeholders.
Me: ;-)

Regards

Lothar

• ▶ Reply

Permalink Reply by Rui Curado on April 2, 2009 at 13:41

Thanks Lothar. That's a very good explanation and example of how the industry is today regarding MDSD.

"About all my writing, what do you think about a CRUD like tool that seems to be an entrypoint in MDSD for the targeted audience (administrators/database administrators)?"

My opinion is that the tool should double as demonstrator and as an evolutive tool: It must be able to demonstrate a new concept in a simple way, but then it must not fall short afterwards. The user must then be able to start doing something, and be able to do increasingly complex stuff. In one sentence : "The tool must be able to do more than what it initially demonstrates"

• ▶ Reply

Permalink Reply by Lothar Behrens on April 2, 2009 at 14:40

Yes, the tool can be used to demonstrate the technology. Also it can be used at an existing database to reverse engineer a schema - even not all yet - to an UML model.

The UML import / export functionality shows a way to bridging to further technologies.
(The tool is capable to reverse 1500 tables in reasonable time, other tools seem not to do at all)

Generally my approach is first try to get it prototypable and store the configuration in a database, then think about how do I model this in UML. And even if I don't have the UML modelability, I have the DSL for it - the database schema, that describes what I want to show in the prototype :-)

And therefore my prototype to model the prototypes in a manner of CRUD actions, shows how a DSL could be implemented.

I am in the development to add form actions (buttons to do something) that are more complex. Thinking about UML activities, I am in the design process to enabling the prototypeability of basic activities such as validations to invoke other actions based on the values in the form or even veto some update to the database by abborting the event.

A basic action that is also usable from the UML model is a master detail action to show the orders for a specific customer. This is rather simple, but having not only an usable way to model, but also a way to quickly show it in a running application tends to the glue that code is also generated as easy as showing it in a prototype.

But it must be reviewed by others, if the tool really does a good job. I only try to achive similar results in MDSD as more complex tools, but try to keep it user friendly to the experienced database admin who could capture simple UML models to be similar to ER models. That is the entry point at the view of modelling. The tool then will create a more complicated UML model as a next step. (Separating the form class from the database table class, thus enabling multible forms related to one physical table).

At the end I must say, that I am mostly a single developer in my project. The project therefore could never gain that complexity as of oAW or the like. That's because I only support XSLT. I haven't the time to support XPAND, XTEND from oAW, velocity or other generator languages :-(

Obviously, there is a possibility: Creating an action that executes other applications and an action that will store the XML model converted to XMI. Thus chaining these actions will get a simple but powerfull adaption against other tools like the oAW workflow.

It's really not far away, but only with the help of external tools :-)

Lothar

• ▶ Reply

Permalink Reply by Rui Curado on April 2, 2009 at 15:20

"But it must be reviewed by others, if the tool really does a good job."

I am in the same situation with my ABSE methodology.

"I only try to achive similar results in MDSD as more complex tools, but try to keep it user friendly to the experienced database admin who could capture simple UML models to be similar to ER models. That is the entry point at the view of modelling."

Well, you got that right. I believe that MDSD will only become mainstream when it gets simple and easy enough to be,... well,... mainstream!

• ▶ Reply

Permalink Reply by Ed Merks on April 5, 2009 at 13:54

I think part of the solution is to tackle the problem head on. Identify all the stupid reasons people have for why they think modeling is stupid http://ed-merks.blogspot.com/2008/09/unbearable-stupidity-of-modeli... and then address each of those specific issues. I.e., demonstrate to people where their thinking has gone astray.

The complexity argument is one that I'm quite weary of hearing. Of course I see it repeated in this very note thread too. Go figure. Did we stop to consider that when those who advocate MDD go around pointing fingers at various MDD technologies and argue that the thing over there is too complicated, we're lending weight to the whole complexity argument? I'm sure you have something much simpler. But consider that things always start out much simpler, they don't stay that way. See Java as a case in point: how come enums were too complex to include initially and yet there they are in 5.0? Simple things are more likely not to be very complete and while simple to learn, will tend to feel restrictive and limiting by the time a really complicated task needs to be addressed. Complex things, while complete, will be more challenging to learn, but will be more likely to pan out into a complete solution for the complex problems that mere developer mortals are faced with every day. Where's the Goldilocks point?

EMF continues to grow in popularity for an important reason. It has direct pragmatic value to the mere developer mortal. They don't need to drink the MDD koolaide first. When I asked the platform UI guys what convinced them EMF was a good thing for e4, they said they measured the performance of a reflective eGet verses a simple HashMap get and found it to be twice as fast. Of course the footprint is dramatically smaller and somehow type safety comes apparently for free. Pragmatic value wins the day. Of course it helps a great deal that EMF is also very useful for building the MDD technology itself, i.e., to build other meta models, like UML, and to build DSLs, like Xtext does.

• ▶ Reply