Custom code junkies beware - DSL Inertia
In his response to my last post, Steven said
"Microsoft's focus on IDE integration seems to be leading many of its customers astray. They're jumping straight in to building tight integration with Visual Studio, before they've even had their modeling language used in practice. The 5-10x increase in productivity with DSM does NOT come from IDE integration -- none of the reported cases have had that. It comes from a good modeling language, fitting the needs of describing applications in that domain."
I don't dispute that in the general case, custom IDE tricks won't buy you a lot of extra productivity over and above the big boost I believe you get from having all of your tools in one familiar place with one set of IDE skills to learn. I personally don't believe that most customers will be using 100% DSM for some time so they'll still spend plenty of time in their traditional IDE.
However, imagine for example, one aspect of your DSL called for mapping custom forms to some of its data. I'd hate for your users to lose some of their new-found productivity by having to use some kludgy form designer or worse still some sort of diagram of a form just because Microsoft hasn't gotten around to integrating the VS forms editor into the DSL Tools in V1. Custom code would make it possible to do this job well if you can justify the spend.
Steven also said in a comment on the AppDevAdvisor blog many moons ago…
"The important thing in a metaCASE tool is that it should do the "heavy lifting" for you. The whole idea is to obtain a CASE tool without having to program it, and without having to learn all about how to program CASE tools well. The metaCASE tool provider is the expert in programming CASE functionality, so you don't have to be. "
Now I do agree that we in the DSL Tools camp forget this sometimes (or as he says, maybe haven't learned it yet). I'm certainly personally more focussed on the experience of creating a DSL rather than the experience of creating business software using that DSL. My day job is focussed on my customer, not my customer's customer.
There's a definite danger that as a developer one can get caught up in the coolness of all the widgets you can bolt on and the level of smoothness you can achieve in integration.
Jochen often reminds us that in our game, it is the business value of the generated designer that really matters and by implication that it's not about hardcore devs becoming Visual Studio SDK experts (or even DSL Tools experts). I guess sometimes you might get the opposite impression by reading our forum :-)
There's a great post by Oliver Steele called "The IDE Divide" where he describes language-centric people as essentially not being tied down by the baggage of a lot of rich IDE tooling but also not getting the productivity benefit of that rich tooling. Instead they get their productivity from adoption of new languages.
I think this applies equally to graphical DSLs. Folk who just use the basics of the tooling but focus on upgrading and honing their language regularly will fall into one camp whilst other folk will evolve their language more slowly but add all sorts of tool-productivity features on top.
In the end, I think a lot of it comes down to the cycle of your business.
If you're using DSLs to boost the productivity of project teams generating data access layers in a consulting firm then you probably need to be super-agile and able to make sweeping changes to your DSLs at the drop of a customer scope-change. The inertia of a lot of custom code may actively hold you back.
If you're a shrink-wrap vendor on an yearly release cycle, with the stability that brings, then investing in a lot of extra integration can add massive value to your customers as they use your DSLs. You don’t have to make big changes to the tool itself until the next cycle - most of your agile customization needs will probably come in your code generators which aren't usually coupled tightly to IDE integration.
P.S. Steven - I will try harder not to misunderestimate you in future ;-)