I was eagerly sucking up the facts the two architects Matthew Wall and Erik Doernenburg are presenting in the podcast.
But after about 20 min I was shuddering: At this point Matthew and Erik are talking about applying Domain Driven Design (DDD), specifically about enforcing aggregate rules, when the host (Markus Völter) was stating the following:
If I had done that, I probably would have defined a domain specific language, for example a textual DSL, that would know about those concepts. Then you could actually write programs using those common language terms as first class citizens.
This made me cringe. I know the Markus Völter is an expert in MDSD and DSLs, but stating the above quote in such a casual manner rings a lot of my alarm bells.
I just have a bad gut feeling if someone wants to build such essential infrastructure up front. That's when my invented-elsewhere-syndrome kicks in.
[YAGNI, Race to Running Software, Less Mass are other things that come to mind ...]
I have just seen too many projects, that invented their very own framework.
In the beginning everything goes smooth and it is very cool to work on TheFramework(tm) and not having to solve the real business problem. You can really feel smart ... But then the 80-20 rule kicks in and all the special cases threaten to turn TheFramework(tm) into a big ball of mud.
And that's even before maintenance becomes an issue of its own ... who is going to hatch TheFramework(tm) when the underlying technology evolves?
I think that endeavors like this should not be taken light-headed. This can cause a lot of suffering.
As my self-confidence as developer is growing, I think I would refuse to work on a project with this premise.
I think it is exactly the point of domain driven design that it is not about technology but about concepts. People too often rush head first into technical realizations. Thats also what Eric Evans says when he mentions that the competent developers often are not invoved in "domain crunching".
On the other hand, some years ago I would not have been so hesitant and precautious. As a highly motivated graduate, I would myself have rushed headfirst into the challange, working on a cool TheFramework(tm) of my own ... So one could ask: Why did I loose my faith?
Honestly I don't know... could it be that I lost my courage in the trenches of enterprise-developement?
The problem with DSLs is easy to explain: Growing and designing a language has been shown to be hard. Most people who think the could solve a problem with DSLs are not good language designers => disaster.
ReplyDeletePeace
-stephan
I think you are just older and smarter. I feel i know too much by now I dont want to learn another one-job framework or language.
ReplyDeleteI think by now writting Util classes is much better than writting frameworks.
I think that people that love DSL are just bored and dont care about people that will have to learn that language. Why if those people know only one language and its not dynamic? it could be very hard for them.
However if I could create some DSL at work than why not, it would be cool to write, but thats about it and i wont have to learn it :)
A couple of comments:
ReplyDelete* Who said I would build the DSL up front?
* Growing general purpose languages is hard. Growing limited DSLs is much easier.
* Also, does anybody commenting here have any actual experience with today's DSL tools and really knows the efforts that go into it?
Markus
Speaking as a "seasoned developer" (20+ yrs), your observation is mostly correct. I too have seen several projects get bogged down in "framework exercises". Sadly, I've even seem some developers who shirk their "real" work and devote almost all of their effort to enhancing TheFramework(tm). But I'd like to back up Markus' point; namely, that we have such powerful tools available now that creating a DSL doesn't mean spending four or five man-months with yacc, lex and a BNF grammar. While it's certainly not to the level that you can just "crank one out" in an afternoon (well, maybe Markus can, I don't know), it's not unreasonable for an architect or senior developer to identify such a need and plan for creating one as part of the initial project planning.
ReplyDeleteI think it depends on the overall technical competency of the developers. If you have gun ho developers that are pragmatic them I think creating a DSL may be the way to go.
ReplyDeleteFirst of all I am just flabberghasted at the amount of feedback I got for my post.
ReplyDeleteI only recently subscribed my blog to javablogs.com and did not really think about the consequences.
Next time I will probably think twice before mentioning somebodys name in a skeptical post.
Sorry Markus, no offense intended!
I certainly do not have enough expertise in creating custom DSLs to give an objective judgment.
However I am skeptical about two things:
Growing a DSL during a project of the size of the Guardian.co.uk (peaking at 104 developers) seems quite a dangerous venture ...
In my opinion a project of this size should be at least be founded on a stable language ... dealing with changing requirements in an agile environment is already difficult enough.
In a smaller project with fewer developers (which probably are evolving the DSL themselves, based on their new insights) this might be possible, but this kind of defies the classical factory-approach...
The other thing is, that in my experience the tooling for working with custom DSLs is far from being as mature as for current general purpose languages.
But as I said these are just my gut feelings, which could well be influenced by my loss of faith ...
@last Anonymous:
ReplyDeleteWhat are "gun ho developers"? I am not familiar with this term...
Are those the Morts from the MS-Classification?