I have a blog over at O’Reilly Network, I try to keep the posts focused on Java, and for the most part the entries tend to attract a fair amount of conversation. I’ve been trying to shy away from overly negative stories, but there are certain subjects on which i can’t help but comment negatively. The various Java sites (O’Reilly, TSS, DeveloperWork) tend to be infected with a bland aversion to criticism, instead of getting good opinated stories, we tend to get corporate marketing blather.
Nathan over at Coderspiel has an interesting reaction to last week’s NYTime article about the gender gap in Computer Science. I resonate with this reaction to the call to deempasize “programming” in a field that should be devoted to programming:
Many academics have exploited the uncertainty of computer science’s boundaries, and the cultural mantra of inclusiveness, to encompass in the field any contribution to computing.
His solution is the right solution “teach it earlier” and “integrate it with other curriculum”:
If anyone is really interested in getting more girls (and boys) into computer science, the answer to teach it earlier in school. It doesn’t have to be “Java programming,” but it does to be programming. Start them off in the interpreter of a scripting language like Python and show the kids how easy it is to create something. Because that is what programming is all about: making things. Move on to pygame and animate some sprites. If students are to be taught Java, start with the hands-on, graphical Processing environment and make interactive art for art class.
And, he closes with this…
Shame on these no-talent hacks for telling girls that the only kind of computer scientists they can be are non-programming airbags—the world’s first programmer managed just fine as a woman.
Take a look at the project, and you’ll notice that it is too “wide” – there are about 50 released plugins and 30+ sandbox plugins, that are all in various states of disrepair. There are released plugins, like the Maven Cobertura plugin, which have been released in a broken state. And, there are projects that seem to work fine. The issue with Mojo isn’t size per se, it is that no one is really paying much attention to the commits and the vote threads, I’m tempted to just create a fake plugin in the Mojo Sandbox, throw some broken code in there and then call for a vote thread: I’m almost certain I’d get a sufficient number of votes to graduate from the sandbox and cut a release.
Releasing Broken Software
The Coberura plugin is fairly important, it is the alternative to the Clover plugin and it produces unit test coverage reports. While Cobertura isn’t as polished as Clover, it provides a similar report, and (most important) it is free to Clover’s ~$250 per workstation. If you’ve played around with the Cobertura plugin from Mojo, you may have noticed that, it doesn’t work as documented, and even once you get it working, all the classes instrumented have 100% coverage.
Hmmm…so the documentation is wrong, and even once you get it working, it doesn’t really work. So….how did this thing get released? Here are some important emails from the vote thread (from this January and February). First an email to Mojo Dev from Brett Porter on Jan 11:
“I’m seeing complaints that 2.1 doesn’t work. Did all those that voted
test it? Are these isolated incidents, or is there something
fundamentally wrong with the release?”
Followed by an equally important email from Joakim Erdfelt on Jan 12:
“It seems to stem from 1 jira – http://jira.codehaus.org/browse/MCOBERTURA-57”
“I missed the vote against 2.1, I would have voted -1 just because of the
BTW, I field about 3 direct emails about cobertura-maven-plugin 2.1 a
day now. I recommend that to all people to downgrade to 2.0 for the
We can probably revert MCOBERTURA-57 and release 2.1.1 as a short term fix.
The long term fix for MCOBERTURA-57 has recently been checked in at the
cobertura (non-plugin) subversion at sourceforge.net”
Then, more than a month later, the discussion is concluded with a question from Brett Porter on Feb 24:
“Ok, but there were definitely problems aside from that movement hack
– so do we need to nuke 2.1 from the repository?”
Brett’s question was met with a resounding silence.
What is interesting about this whole discussion is that none of the five people who voted +1 on the release bothered to answer the question posed by Brett Porter: “Did all those that voted test it?”. All those +1 votes came within 24h of the original vote email. One can only conclude that no one even bothered to check it out and test it. The people who voted +1 on this particular release probably never even bothered to use the software. If they had given it a try, they probably would have released that the documentation was wrong.
Some developer just giving a knee-jerk +1 on a developer mailing list translates directly into some user getting so frustrated with Maven that they give up. People just voting +1 on a release because it’s Mojo and they can’t be expected to test every plugin release just creates frustrating software.
Off to JavaOne in a few weeks, I’ve got my schedule set, and I’m trying to decide what’s worth paying attention to. Clearly JRuby is something to watch, from the JIRA issues and Subversion commits, it looks like the JRuby team is furiously focused on getting something to call “finished” by the big conference. The things I’m interested in the most are: JRuby, New Language Features, and anything that related to opening up JCP and/or OS licensing.