Feed on

The Double Dawg Dare

My favorite part of coaching?  There’s no doubt:  it’s the Double Dawg Dare.

Picture two kids in the south of the US.  One of them urges the other to commit some sort of dangerous and cool crime, like, say, getting to the top of the barn and jumping into that big pile of hay down on the ground.  The other demurs, “I’m not gonna do that!”.  The one must now invoke the potent magical energy of a double-dog dare:
Tom Sawyer was a Darer!

“I dare ya.”


“I double dare ya.”


“I double dog dare ya.”

“Welllllll, alright.”

See, I travel around coaching teams in transition, which means I am ever and always ‘the new codeslinger in town’.  Extreme programming has a number of practices that are specifically aimed at the act of coding, which means it’s up to me to work with developers while they get the basics.  A lot of what I do is just code along with them, showing how the XP way of working is more pleasant and productive than theirs.

And here’s the rub: no geek wants to invest in the new codeslinger until it’s been proven that she’s not a bullsh snake oil salesman.  Oh, come on.  I know you’ve done it.  Some so-called expert shows up, and the first thing you have to do is decide whether she knows as much as you.

So what happens? I’ll be working with a bunch of developers, and getting no traction at all. Everyone just nods politely at me, then goes about doing whatever they would normally do.  Then, all of a sudden, everybody hangs on my every word.  What changed? Easy.  I did something technical that they thought qualified me as good enough at geeking to show them something.

Now, my motto is “Fool me once, shame on you. Fool me 387 consecutive times, shame on me.” Which is to say, I gradually realized that I was going to have to demonstrate a gift for geekery for every team, every time.  Once I started looking for it, sure enough, the double dawg dare was obvious at every site.  Some sites have some very advanced standards, others have embarrassingly low standards, but they all have some standard.  I finally just started walking in and saying: “Please take me to the worst class in the system that actually does real work.”  I wanted to get the double-dawg out of my way.

So anyway, I bring this all up for a reason:  I’ve decided I want to offer you a preemptive double-dawg-dare reverse challenge.

Got a java class that is

  1. unbearable, and
  2. untested, and
  3. legal to show the world (anonymously if need be)?

Because that’s what I want. I will wrestle with it, in public, until I have brought it under microtest.

Remember, for this one I’m specifically asking for java only.  (I’m a sucker for Eclipse, and of course, it’s at its best with Java.)  After I get a few entries, I’ll choose one and get started.  Note: I do not need its dependencies, just the source code of the class itself.

I double-dawg dare you to send me a double-dawg dare java file.

(Or are you just a big sissy?)

11 Responses to “The Double Dawg Dare”

  1. r. says:

    ‘microtest’ links leads to a 404…

  2. Kristof Neirynck says:

    the correct link for “microtest” is:

  3. Andy Palmer says:

    This is really useful advice, thank you for making it explicit.

    This is going straight into my toolbox :-)

    I am looking forward to seeing your account of the challenge

  4. class HelloWorldApp {
    public static void main(String[] args) {
    System.out.println(“Hello World!”);

    It’s on now, Mike

  5. Brian Marick says:

    It’d be nice if you could do this on github or someplace like that, so that the entire world might look at the differences between commits. I imagine something like a time-lapse movie, perhaps with running commentary recorded as you’re doing the refactoring.

  6. Nick Pellow says:

    I Double Dog Dare ya!
    FastPageParser from Sitemesh 😉
    Or for something a bit smaller – what about XWork’s SpringProxyableObjectFactory, or PropertiesReader: http://clover.atlassian.com/browse/xwork/proj-risks.html

  7. This is one I couldn’t resist. I wrote Complexian, so I’m seeking out bad code with it all the time. I test it by running it against open source projects to see what I can find. Here’s two candidates for you. The numbers listed are the NPath complexity of the methods at that location.

    From the Java source code itself:
    jdk-1_5_0-src-scsl/j2se/src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java:1322: Complexity is 7693507144912343066

    From struts:
    struts-2.1.6/src/core/src/main/java/org/apache/struts2/components/UIBean.java:616: Complexity is 8134399640484

  8. […] back yesterday, and GeePaw’s love for his flock required him to immediately advance the DoubleDawgDare […]

  9. Jeff Grigg says:

    I teach the value of integration testing over unit/micro testing. While higher level tests are harder and more costly to write, I find that they enable refactoring. And I find that unit/micro tests often discourage refactoring because the tests are so closely tied to the implementation: There are valid refactorings that break the tests – denying you the benefit of having tests to protect you from errors in refactoring.

  10. […] this latest in the DoubleDawg series, we are almost ready to do something […]

Leave a Reply

AWSOM Powered