The trouble with being conventional

"Convention over configuration" is a popular paradigm in developer circles these days. Instead of explicit instructions over every detail or action, you would follow the framework's conventions and get most of the work done implicitly and for free. Ruby on Rails made this idea really take off, and we see it in action in many frameworks. The popular build tool Maven also adopts convention over configuration, and in the process demonstrates how not to do it.

I've had a pretty rough time getting comfortable with Maven. This was a green field Java project: we were starting absolutely from scratch. There were no legacy build processes to support, so we were ready to follow Maven convention everywhere. Nevertheless, it has been a long, painful (one colleague said "character building") journey. Why did it have to be so hard?

Chasing abstractions

We Java enterprise developers love abstractions in code. I suspect the typical software geek comes up with new abstractions more often than he changes his underwear. I admit to writing code with premature abstractions, such as using a strategy pattern where I end up never using a different strategy. We code defensively, afraid that lack of flexibility will hinder future changes. But beyond the code that we actually write, Java enterprise developers also love abstractions in third party libraries. We chase abstractions, in search of that fantasy land where if we adopt this or that framework we need not change our code to accommodate the hypothetical need to change the underlying implementation. The result is comic levels of abstractions upon abstractions.