Maven as a Candidate: Winning Over the “Undecideds”

It isn’t a perfect analogy, Maven isn’t constantly having to raise money or make tough votes on legislation, but I’ve always thought of Maven as a politician with an established positive base and an established negative base. Like any politician, there is an established base of people who are predisposed to “vote” for you, there is an established base of people who are predisposed to “vote” against you, and then there are the valuable undecideds. This is the real audience, you don’t fight for your base, you try to convince the undecideds to vote for you.

If you were trying to campaign for Maven, you have three options:

  1. Convince the Opposition – It doesn’t work. If you are deadset against Maven in 2010, you are probably not going to move toward Maven in the coming months unless something dramatic happens. Ok, that’s not true, I’ve seen this work, but you can’t make a direct attack on the opposition, you have to cede some ground to gain some ground (but that is a different blog post).
  2. Play to Your Own Base – Believe it or not, this is important. If you lose your base, you’ve lost your support. Maven’s in the #1 spot for build tools at the moment, but in technology things can change quickly. Maven’s base is under an almost constant assault from people peddling other options. Your base has to feel supported.
  3. Win Over the Undecideds – This is where it gets interesting. Since Maven is constantly under attack (deserved or undeserved) we’re constantly seeing people Tweet or comment about having to make a decision about Maven. The competition tends to attack Maven’s deficiencies, and it is easy to get baited into a fight about the deficiencies of alternative tools.

Winning Over the Undecided

Arguing over Maven’s “problems” with the competition is unproductive. You might score points with your base, but undecided voters just see conflict. Think of a nasty political campaign with negative ads: it almost always depresses turnout on election day because undecided voters just don’t care. All they see is a nasty fight. (You might think I’m being overdramatic here, but development infrastructure has sparked passionate, all-out fights, it is something programmers *care* about.)

These fights are unproductive because as soon as you let someone bait you into a fight (“Maven can’t do XYZ, blah blah blah”), you are playing in a lop-sided arena. Yes, Maven has a somewhat verbose approach to configuration if your build is highly customized. Yes, Maven’s repository has some edge cases that make dependency exclusion difficult (but not impossible). If you start answering every single criticism about Maven, the conversation starts to focus on deficiency.

The best strategy is to turn it around. Focus on what Maven allows you to achieve, acknowledge the problems with the tool, and then talk about continued investment in improving it. I’m pretty sure this strategy works, but more importantly you don’t come off as being a combative jackass. Again, back to the politician analogy. Have you ever seen one of those knockdown election cycles full of negative ads and scandals. The victor always ends up sullied by the experience. This is not to say that there’s never a good time to answer dishonest criticism, but it has to rise to very high level to gain acknowledgement.

Remember, there’s a baby in that bathwater…

There are problems with every tool, when you tackle a problem as difficult and universal as project builds you are bound to make someone unhappy. When you “mess with” a programmer’s set of tools, you are going to get complaints from artisans who disagree with fundamental design decisions. Hell, I disagree with a few decisions in core Maven, but, on balance, my experience is more positive than negative.

Do I often spend a few hours debugging some crazy resource filtering issue that makes no sense even after I have fixed it? Totally. But, I’d have much worse problems if I were trying to debug my own, customized build script. Would it be easier to fix a specific problem? Yes, because I would have created the build system myself. But, that’s not the point, the real benefits of Maven are not the direct, first-order benefits, they are organizational. If someone comes up to me and asks how to build the system, I can tell them to checkout the source code and run “mvn clean install”. That’s it. It works very well in my IDE, and I can also use it to deploy applications to production. It runs complex integration tests out of the box with minimal configuration, and there is a wealth of plugins available.

Does it have problems? Yep, but there’s a community working hard to address these problems. Will they ever be “done”? Will Maven ever be perfect. No. But, If you are considering voting for the other guys, I would like to remind you that there’s a baby in that bathwater.

Loukides Captures the Key Difference in Google v. Apple Strategy

Mike Loukides writes “App Inventor and the culture wars” on Radar this morning. Here’s an excerpt:

“Apple is saying “trust us, it will just work.” Google is saying “We’ll help you to be creative and make your own stuff that works for you.” There’s nothing inherently wrong with either approach. Apple’s approach is more appropriate for an entertainment device, more like the 60s TV, radio, or dial phone. It does more, but it’s still sealed; you can’t open it up and hack it. There are plenty of people who want that kind of experience–possibly a majority. Google is opening up the guts and letting you create–and taking the gamble that people who haven’t been creative in the past will start.”

Go read the full post on Radar.

Mirah: Taking Performance to the Next Level with Java’s Ruby

I published a short interview with Charles Nutter on Mirah, an attempt to modify the Ruby language ever so slightly to create a new language that can be compiled to bytecode. What differentiates Mirah from Groovy, Scala, and other JVM-based languages is that Nutter wants a language that can compile directly to bytecode with no runtime dependencies.

Read the full interview here

In defense of Maven

Steve Ebersole’s wrote a “This isn’t a rant” rant on the JBoss community site where he proceeds to attack a series of Maven straw men. I’m not going to get into it, other than some quick responses:

1. Docbook? You have a hard time managing DocBook with Maven? C’mon – I manage a library of books with Maven all of which are written in DocBook. The artifacts are deployed to a repository manager, and the builds are all run through Hudson. We spit out ePub, PDF, HTML using the docbkx work from Wilfred Springer.

2. You can’t build a submodule in isolation? Again, this is a straw man. Maven’s parent -> module relationships are not always symmetric with child -> parent relationships. Gradle solves this by making a simplifying assumption that they always are. This isn’t always accurate and it would screw up a number of projects I work on. Plus there are reactor options to give this man what he was asking for, but he doesn’t like how they work. That’s fair, but more style than substance.

3. Maven doesn’t support multi-module builds… Wait, what? Yes it does.

4. The Release plugin isn’t worthless, I use it all the time. It saves me a tremendous amount of time. It works well with Git and Subversion, and without it, I’d have carpal tunnel syndrome. There are edge cases where it doesn’t work, when I hit those, I use “mvn versions:set”, and (GASP) I execute version control commands. It isn’t that bad, really, it isn’t. Now the code for the release plugin is a different matter – the Release plugin is one of those mega-plugins like the Site plugin – it is a world unto itself. That needs to change.

I repeat: I use the Maven Release Plugin all the time, it saves me considerable time. If you want to fault anyone for how difficult it is to use, fault me. I still have not written a chapter on the damn thing.

Other than that, let me know how it goes. Gradle looks interesting, but not interesting enough to sacrifice everything I get with Maven.

Beyond JRuby: Nutter’s Mirah

Developing with JRuby is interesting, but it is also something of a challenge to deploy. If you develop applications deployed with JRuby Rack, I’m guessing that you probably don’t bother starting a JRuby Rack web application as a part of your development cycle. In my experience, JRuby Rack is great, but the startup times are challenging. The solution? (It isn’t satisfying…) Use C-Ruby during development and start Rails with “ruby scripts/server”. If you do this, you are forced to either avoid Java-Ruby integration features of JRuby, or you are forced to avoid anything interesting during your development cycle.

Why bother? If you are deploying a massive, “enterprisey” application, you’ll use JRuby because it simplifies the deployment story. Your operations team wants a handful of WARs, they know Java. Believe it or not, this is a compelling reason to select a technology. The line between operations and development is covered in carnage, and you certainly don’t want to be “that developer” that forces the operations team to adopt mod_passenger or mongrel only to be getting 3 AM calls from someone not particularly interested in the compelling reasons to adopt a different platform. (I’ve been there.)

Nutter’s Duby language was something he’s mentioned a few times on Twitter. I haven’t spent too much time looking at it, but it looks like a promising alternative to Groovy. What interests me about this project is that it offers a Ruby-ish language syntax that can spit out bytecode. No need to carry around JRuby dependencies and rely on hackish Java-Ruby hybrids just to get things to cooperate. He’s evidently changing the name to Mirah, check out the Mirah project page for more information.

And if you are too lazy to click on that Mirah project page, here is Nutter’s presentation from Rubyconf 2009 on Duby: