Visual modeling: Is it worth it? An example...

The following link points to an interesting article (in German):

Groovy-DSLs mit Eclipse-GMF visualisieren

The article perfectly shows some of the issues I have with the current state of visual modeling and MDSD.

The first part of the article is about implementing a domain concept. This is directly connected to the business problem which should be solved by the software at hand.

The second part of the article is about making the solution of the first part accessible for visual modeling.

I did quite easily understand the first part. The second part however seems a lot like rocket science to me (or some secret ancient ritual). There are a lot of steps and different concepts involved (code, configuration, libraries, guis, wizards, repetitive reflection of the actual domain concept, mapping ...).

While I feel confident, that I learned something from the first part (creating a simple textual DSL with Groovy Builder), I do not have the feeling that I learned something useful from the second part, except that it is very complicated to use GMF...

In my opinion, as long as setting up (and maintaining) visual modeling for a certain concept is so much more complicated than the underlying concept itself, visual modeling hardly pays off!

You really have to evaluate costs versus benefits. And in my experience this is almost never done properly.
In the given article: What is the real benefit of visually modeling the process-chain?
Who is the target? Who will be using the visual modeling capabilities?
Are stake holders really able and willing to grasp the visual models? Or are you still going to communicate with them by Visio and Word?
If it is not for the stakeholders, do developers really like to work with the visual models, or is the simple textual DSL much more preferred by them (easier handling with current tools (refactoring, diffing, versioning ...))?

If you think about these questions, is the effort put into the infrastructure really worth it? The article says itself:

Indeed the learning curve [of GMF] is very steep. [...] To gain a better understanding there is often no other way than explore the GMF-Code with the help of a debugger.

This quote alone would rise a big questionmark if I were the project leader of a project that is actually supposed to provide business value...

In my opinion visual modeling is vastly overrated, and especially in the current state is hardly worth the effort.

In my experience any large-scale modeling efforts often turn very fast into a completely disconnected reality-loop. People are wasting a lot of effort just to conquer the accidental complexity that is introduced by the modeling requirement. The actual business requirement then comes only at second priority.

The metaphor that comes to my mind is this:
At the beginning you have a business goal, that is like the requirement to cross a river. But once you jumped into the river, you notice, that you vastly underestimated the current.
From now on you are fully occupied to keep your head over the water. Reaching the other side (not to mention at the specified spot) is of no priority at all any more.

follow me on twitter, I need some friends :-)

Some developers have good taste ;-)

From a unit-test of OpenEJB:

movies.addMovie(new Movie("Quentin Tarantino", "Reservoir Dogs", 1992));
movies.addMovie(new Movie("Joel Coen", "Fargo", 1996));
movies.addMovie(new Movie("Joel Coen", "The Big Lebowski", 1998));

I think I could find some common interests with this developer :-)

follow me on twitter, I need some friends :-)

NetBeans Showstopper: Running Tests

Update 2009-07-02: Adam Bien has some related info here, but this still does not solve my issues (easily running single test methods, failing JUnit tests in maven projects, crappy TestNG integration in maven projects)


Basically I like NetBeans. I have been successfully prototyping applications in NetBeans, and especially the Glassfish integration is superb.

Unfortunately all the commercial projects I have been working on had been using Eclipse. Compared to Eclipse, I think NetBeans is much more intuitive to use and better organized.

Another advantage of NetBeans, is the native Maven integration, which seems still to be a major kludge in Eclipse.

Recently NetBeans 6.7 was released. This motivated me to toy around a bit.
But soon I encountered a major showstopper: the infrastructure to run tests is really poor!

It seems not to be possible to run single test methods!
For me this is just not acceptable. To do micro-iterations and test-driven development, I have to be able to run single tests.

NetBeans only offers to run all Tests of the whole Project or the tests in a given File. That is just not good enough!
Both Eclipse and IntelliJ can run Tests on any granularity level (method, class, package, project), and I am heavily using this feature.

According to this bug-report, it should be possible to run single test methods for Ruby development in NetBeans, but I did not verify this.

Also the TestNG plugin seems to provide this functionality for projects using TestNG.


When I tried to run tests in a Maven project the situation got even worse! Basically I was only able to run all tests of the whole project.

With JUnit, while running the tests for the whole project (or from maven on the commandline) succeded, running the Tests from a single file failed (the project was a simple example from OpenEJB).
Both Eclipse and IntelliJ had no problems running the single tests of exactly the same project...

Running TestNG tests in a Maven project (I tried Hibernate Envers) was possible, but the IDE always delegated to Maven to run the test goal, which resulted in all tests beeing executed... slooooow... it did not matter if I chose to run a single test method or the tests in a file.
Again, both Eclipse and IntelliJ had no problems running the single tests of exactly the same project ...

Unfortunately I have to come to the conclusion that NetBeans is unusable for me, and I think for any project, that sets a focus on developer testing ...

Maybe I am overlooking something, then please enlighten me ...

Googling showed that also others had the same issue: here, here and here ...

follow me on twitter, I need some friends :-)

Maturity of DSLs as a concept

I like the following quote from Jay Field's screencast The 5 Ws of DSLs:

The DSL movement is in a stage that is similar to the stage of OO before Design Patterns were documented.

- Jay Fields, InfoQ

The concepts for DSLs are slowly being fleshed out. As experience is gained, best practices will evolve. But we are at the beginning of this process!


Along those lines:

Overuse of DSLs is one of the antipatterns in Groovy development.

- Dierk König, Gr8Conf

Do not create a DSL if a native solution would be as elegant.

- YADSL Rule

Some DSLs will live and some DSLs will die...

- Rocky Lothka, .NET Rocks Episode 417

follow me on twitter, I need some friends :-)

Programming humor continued: Airlines

Thanks Stefan for pointing me to this:

If Programming Languages ran the Airlines

and not as funny as the above:

If Operating Systems Ran The Airlines...

This post joins the ranks of hilarious episodes of programming humor:

A Brief, Incomplete, and Mostly Wrong History of Programming Languages

Language Wars

Web Framework Trolling

If programming languages were religions...

If programming languages were cars...

follow me on twitter, I need some friends :-)

Restarting the embedded OpenEJB container between each test

If you are looking for an embeddable EJB3 Container for your unit-tests/integration-tests, OpenEJB is currently the most mature solution (alternatives are embedded Glassfish and JBoss embedded).

The documentation and the samples of OpenEJB are really neat and enable an easy jump-start. All the examples are automated tests that run with a simple mvn clean install.

After a while however I came across the following problem: The embedded container is not restarted by default between tests. If you have two tests (even in several test classes), each starting the embedded container, then the second test gets passed the same instance of the embedded container as the first one.

This has the potential for shared state between the tests and strange side-effects as a consequence.
The first occurrence is when you are accessing an (sandboxed) database, that gets initialized (hibernate create-drop) when initializing the persistence-unit. Since the container is not restarted for the second test, the persistence-unit does not get initialized a second time. This means you have all the traces from your first test in the database...

An easy way to work around this, is the undocumented feature of OpenEJB to destroy the container when closing the initial context.
This is achieved by setting the property "openejb.embedded.initialcontext.close" to "destroy" on the InitialContext.

Now my test harness looks like this:

@Before
public void setUp() throws Exception{
	Properties p = new Properties();
		
	//Set some other properties like datasources ...       
	p.put("openejb.embedded.initialcontext.close", "destroy");
        
	context = new InitialContext(p);
}
	
@After
public void tearDown() throws Exception{
	context.close();
}

It should be kept in mind, that restarting the embedded container can have implications on the performance.
In my first tests on my MacBook, the repeated startup of the container takes about 200 ms, which I find acceptable for integration tests... but probably the concrete deployment scenario has an influence on the startup time ...

follow me on twitter, I need some friends :-)

Raising the Level of Abstraction

Abstraction is a central concept in software development.
Abstraction is probably our only hope to conquer the ever rising complexity and requirements in current and future systems.

When designing a software system today often there are no physical constraints. The only constraints are intellectual: Is the design understandable, maintainable, what are the effects of future changes ...

Abstraction is supposed to be a tool to do the right choices when designing.
But what is abstraction really? How do you characterize it? How do you measure it?

There seem to be a lot of different notions about how to raise the abstraction level.

Some people talk about nonterminal symbols:

<integer> ::= ['-'] <digit> {<digit>}
<digit> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

Some people believe in pictures and visuals:

Some people see hope in reducing the signal-to-noise ratio of code:

[...] a lot of Java programs are the boiler plate of controlled structures with very little business logic. It's probably a four or five to one ratio between business logic and boiler plate control structures. So Ruby gives you that conciseness.
You are saying: "Here is the business logic, apply this business logic [...]

-- David Pollak, InfoQ

For me, the third approach is currently the most promising. That's where DDD tries to pull the lever. That's where concepts like the Ubiquitous Language and Domain Specific Languages try to provide value.


And finally remember Joel Spolsky's Law of Leaky Abstractions:

All non-trivial abstractions, to some degree, are leaky.

follow me on twitter, I need some friends :-)