Making Model-Driven Software Development live up to its promises
Model Driven Development proponents see a lot of advantages of using MDD techniques. Higher development speed, increased quality, more cost-effective, empowering less-experienced developers, just to name a few. If you look at these promises the question arises why the whole world isn’t using MDD right now? Why don’t we hear a lot of MDD success stories?
In a recent article I wrote about some of the main concerns which prevent people to use MDD, as mentioned in this StackExchange thread “Why aren’t we all doing Model Driven Development yet?”. This article triggered quite some discussion and you should definitely read the comments! I wrote this article as a warming-up for the fishbowl discussion session I hosted at Code Generation 2011 two weeks ago. In this session, titled “Making Model-Driven Software Development live up to its promise”, we discussed the future of MDD in four sections, to cover subjects like popularity / marketing, creating alignment between programming and MDD, focusing on domain experts, and education. It was a great session with lively discussions and I want to share some “sound bites” with you in this post.
- We need to convince developers to start using MDD.
- It’s a social change: we need to move to a separation between language designers and language users.
- The success stories of MDD are not shared because of the competitive advantage. Real success stories are often very domain-specific.
- Generate the boring stuff, make developers happy!
- As the market grows all current developers can move to language design. Language users can be a new group of people.
- MDD is too hard to explain in one sentence. Complexity is a barrier.
- The message of MDD needs to be mapped to business bla, but it should be different than other tech messages.
- XP (eXtreme Programming) is successfully marketed by connecting it to incremental development / agile.
- We need a different name. Nobody will buy MDD, it’s already dead from a marketing perspective.
- Focus on agile, that’s the value proposition of MDD!
- We need metrics to measure the success of MDD.
- MDD supercharges Agile and Lean!
Alignment with programming
- In certain communities it makes no sense to distinct between modeling and programming.
- There is no difference: just a language at the right abstraction level.
- MDD is only useful to bridge the time between steps in 3GL languages.
- The mainstream feeling about language design is that it is very complicated. People don’t know that the tools have evolved.
- Are we as an MDD community our own biggest enemies? All “old” discussions will always come along, e.g. textual vs. visual languages, etc.
- API is a model, a DSL. People are creating abstractions all the time.
- Building linguistic abstractions IS different (a lot of discussion about this statement).
- There is a projection possible from an API to a language, but they are not isomorphic.
- We are good at language processing, so there is a case to create a language instead of just an API.
- Using or creating a language asks for a different skillset. Be aware of the difference and approach developers with a different story.
Focus on problem domain
- Move languages to the language of requirements.
- Make languages specific.
- Involve domain experts, use the existing notations of a domain.
- Do domain experts want to have a tool to build software? No, they don’t want to specify all details. They have no time for it. They only want to say yes or no.
- Programmers / analysts need to translate words to models and focus on the exceptions.
- It can be important that domain experts can READ models.
- Domain experts DO want to have a tool to build software… focus on the domain experst who are working as analyst or consultant.
- Fast feedback cycles are important. “Is this what you want?”
- New job title: configurators.
- Focus on the middle man! The one inbetween business and IT.
- There is not enough critical mass to be successful when we focus on domain experts who want to “program”.
- Focus on the ones who understand the domain (not only the ones in the domain / the customers).
- The biggest problem is to have a domain expert available to build the language. You need someone with a very deep understanding of the domain to design a domain-specific language.
- We as an MDD community failed: we didn’t bridge the gap between business and IT… we need a new role now? (the middle man).
- Universities don’t teach MDD or modeling. There are people leaving universities who are not able to read a UML diagram.
- Or it leaves a bad taste because of the mandatory waterfall use cases.
- The problem is a generation gap. The renew time of professors at a university is 25 years, so you can only innovate every 25 years.
- Universities shouldn’t just focus on preparing for the job market. They should look further.
- People need to learn more than one programming language to understand the concepts as grammars and trees much better.
- We need to improve productivity, hence problme domain languages are needed.
- Universities should create open minded people who will accept new languages.
- You cannot create a simple DSL on top of complex UML.
- De-empasize UML education.
- The more human languages you learn, the more open you are to new languages. Minds will open!
Thanks to all attendees for the great discussions! I guess you also have a meaning about these subjects? Post them in the comments and keep this discussion going!