Home

News: Martijn Verburg: Brilliant advice from a Java veteran

  1. A constant theme at JavaOne is the idea of everyone working together to make our platform of choice the best that it can be. This philosophy was perhaps best exemplified in the joint session moderated by Martijn Verburg , Bruno Souza and Heather Vancura entitled 101 Ways to Improve Java. All  parties involved pushed a number of useful ideas that any motivated Java developer could engage in, from starting a local Java User Group (JUG) to supplementing the documentation for an under-serviced component in the OpenJDK. Most of the advice was pretty much on the mark, although at one moment during the session the otherwise lucid Martijn Verburg seemed to loose his mind as he provided some of the worst advice ever spoken at JavaOne. Martijn suggested that a good way to move the Java platform forward was for people to actively report the various bugs they encounter.

    Bad advice from a diabolical developer

    At its heart, it’s good advice. After all, there’s nothing wrong with reporting a bug. Bugs need to be identified before they can be fixed. The issue here is suggesting that the Hoi Polloi should be actively reporting them.

    Sacha Labourey, CEO and Founder CloudBees knows what I’m talking about here. Back in his old JBoss days he saw what the support staff went through as they helped clients sort out their problems that they were confident was a bug with the vendor’s software. “In 99% of support cases it is never a bug. It’s always a problem in their application or their configuration that they, the client, can’t figure out.”

    Of course, as Sacha points out, when you’re supporting a product, it doesn’t matter where the problem lies. You help your customer fix their problem, and you never mention the fact that what they originally reported as a bug was in fact a problem on their own end. Rarely is a reported bug really a bug, which is why we shouldn’t be encouraging everyone with an installation of the JDK to start calling up the Oracle help desk when they don’t like the way their applications behave at runtime.

    Mr. Verburg really should know better. After all, Martijn is a hugely respected member and bartender over at the Big Moose Saloon on JavaRanch, and he knows the type of problems newbies run into when they start programming in Java.

    Personally, I’ve done a batch of work in the WebSphere Portal world, and that means encountering a large number of mysterious behaviors and non-obvious features. Whenever a portlet fails to render, or a user is mysteriously given someone else’s session data, there’s always someone in the office that throws their arms in the air after a few minutes of troubleshooting and says “let’s open a PMR on this one.” Of course, the problem is rarely, if ever, significant enough to justify kicking off an IBM Problem Management Request (PMR), but it’s always a trigger the less experienced want to pull.

    And that’s the problem with suggesting that people should more actively report bugs: the bugs they will end up reporting won’t be bugs at all, and tracking and closing these erroneous bug reports just wastes the time that could be better put towards fixing real problems.

    We forgive Martijn. We know that his heart is in the right place. But let’s not encourage the populace to start actively reporting what they perceive to be bugs. Let’s encourage them to post to message boards like StackOverflow or the CodeRanch. Then, when an experienced moderator, like Martijn himself, recognizes that a given issue really is a bug, he can report it with the added authority that comes with his name, reputation, and status as a CodeRanch bartender. That way we can save a load of time and effort by making sure that product development teams are tending to the things that really need fixing and not wasting time chasing red herrings.

     

  2.  

     

    “In 99% of support cases it is never a bug. It’s always a problem in their application or their configuration that they, the client, can’t figure out.”

    And that’s the problem with suggesting that people should more actively report bugs: the bugs they will end up reporting won’t be bugs at all, and tracking and closing these erroneous bug reports just wastes the time that could be better put towards fixing real problems.

    Couldn't it be that when problems are not actively reported by direct or indirect clients, in this case the encouragement for such activities is low and not enough feedback and statistics is recieved to drive the further improvement of the interfaces, functionality, availability, security etc.? But when the encouraged people start overwhelming the support with the such help requests, be it a configuration, inter-communication issues, API usage or something else in 99% of the cases, couldn't it be that these are indicators that something is inherently wrong with the product presentation, documentation availability, training, social awareness, or even issue reporting process, which should be improved? How the company and the teams would be aware of such process flaws if no extensive feedback is reported, and users (direct or indirect) are encouraged not to report any issues they beleive mightn't be the bugs in the underlying software?

  3. Hi all,

    It's a shame that Cameron didn't come along to the BOF on the commnuity and the OpenJDK where we covered this exact topic.

    In fact there will be a dediccated OpenJDK project in the new bug tracking system where all new bug reports go into first. The experts in the general community will work on triaging these types of bug reports *before* they go into the main OpenJDK bug tracker.

    Problem solved :-)

    Cheers,

    Martijn (aka the Diabolical Developer)

  4. Awesome title BTW - couldn't have done better myself :-)

  5. unnecessary and ill-informed[ Go to top ]

    An important member of the Java community is described as such because they care about Java.  Getting the Java community more involved in the Java development cycle is always a great idea.  Anyway community involvement has been the Java trend lately with OpenJDK, JSR in the open, Adopt a JSR, etc.

    Seems like you didn't have the complete picture.

  6. unnecessary and ill-informed[ Go to top ]

    An important member of the Java community is described as such because they care about Java.  Getting the Java community more involved in the Java development cycle is always a great idea.  Anyway community involvement has been the Java trend lately with OpenJDK, JSR in the open, Adopt a JSR, etc.

    +1 :-)

  7. Having dealt with both major "professional" support operations (which only care about closing tickets, since they're paid for that) and open source software projects (where committers' compensation isn't typically linked to the bug tracker), I hugely prefer the latter.

    It all depends on the bug: When developers meticously determine a bug, its root cause, and a way to reproduce, and post that as a bug report, it becomes both easy and desirable for the maintainers to work on it. So, no, we're not talking "my program is slow -- you suck" kind of bug reports here, but the ones which point a spec violation, an I18N error or a bad API. Whenever I post those kinds of bugs, they are usually welcomed, and it really does contribute to a better product in the end.

    Having a good bug writing guideline is pretty important, and judging by Google's search results, OpenJDK could do better in this area...

  8. A bug is a bug is a bug ... or not[ Go to top ]

    "mysterious behaviors and non-obvious features" -  From the post above

    Maybe we could say that these are just "bugs" in the documentation and training material. We should not be talking down to someone who finds these sorts of behaviors and reports them. If the "product" is meant to be used, this stuff should be clear and easy to understand.