Heinz Kabutz on Bad Code, Unit Testing, and More

[Veloso]

Sun's main Java site has an interview with Heinz Kabutz, (http://
java.sun.com/developer/technicalArticles/Interviews/community/
kabutz_qa.html) the a "Java Champion" and creator of the "Java
Specialists Newsletter". He's an impressive guy and says some
provocative things I don't entirely get:

"The java.util.Arrays class is a good example of bad code. It contains
two mergeSort(Object[]) methods, one taking a Comparator, the other
using Comparable. The methods are virtually identical and could have
been merged into one with the introduction of a DefaultComparator that
would use the Comparable method. The strategy pattern would have
avoided this design flaw."

I've always liked "Arrays' and the way Java makes it so easy to
manipulate arrays with searching, sorting, filling, comparing etc. I
don't see how the "design flaw" makes such a big difference. It seems
to me that Kabutz is just being picky, but I'm probably missing
something.

Can someone explain why this really matters in actual coding?

Kabutz also gives Java developers a hard time for not unit testing. He
argues that it's a major problem and that few Java developers do it.
I'm curious: Has anyone gotten into big trouble for not unit testing?
Is it a major source of bugs in your experience? It's not a big
problem among people I talk to -- a limited sample.

Are there any non-unit testers who are as blithe about this as I am?

Kabutz is fun in that he talks about the pleasures of sitting on the
beach and coding in Crete where he lives. He also absolutely does not
get why open sourcing the platform is a big deal. Certainly to most
Java developer, it's pretty irrelevant...

 

[Hunter Gratzner]

I've always liked "Arrays' and the way Java makes it so easy to
manipulate arrays with searching, sorting, filling, comparing etc. I
don't see how the "design flaw" makes such a big difference. It seems
to me that Kabutz is just being picky, but I'm probably missing
something.

Hundreds of such "small" flaws add up to a big misery. And there are
more than just hundreds of such flaws in Java. Each one as such
doesn't matter, the sum matters.

Some call it attention to details. It is what in my book separates the
lazy programmers from the real ones, the boys from the men. It is an
attitude thing. The "I don't care, this is just a job, the code
somehow works for me" programmers are the ones I fear most.

I'm curious: Has anyone gotten into big trouble for not unit testing?

Define "trouble". If you mean in the sense of "ups, we could have
found this bug earlier if we'd had some kind of unit testing". Then
yes. I have done many root cause analysis where a serious bug could
have been found with a high probability during unit testing - if there
would have been one.

If you mean in the sense "boss gets angry". Yes, I have seen that,
too. Wasn't my project, I was just called to do some root cause
analysis. Boss didn't like what the analysis showed, in particular
because unit testing was officially something to be done but was
skipped.

Is it a major source of bugs in your experience? It's not a big
problem among people I talk to -- a limited sample.

The code, not the testing is a major source of bugs (specifications
are another). Your argumentation is typical in some areas, shooting
the messenger. If we don't look very hard we don't see many bugs. If
we don't see many bugs we can pretend there aren't. If we pretend
there aren't bugs we don't have to fix them, we can keep our delivery
schedule and get a bonus.

Kabutz is fun in that he talks about the pleasures of sitting on the
beach and coding in Crete where he lives.

That is actually the part in his newsletters I find rather boring. He
has repeated this nor a hundred times or so. I think his readers now
fully well know that he is sitting on the beach coding.

 

[Mike Schilling]

Kabutz also gives Java developers a hard time for not unit testing. He
argues that it's a major problem and that few Java developers do it.
I'm curious: Has anyone gotten into big trouble for not unit testing?
Is it a major source of bugs in your experience? It's not a big
problem among people I talk to -- a limited sample.

Are there any non-unit testers who are as blithe about this as I am?

The only way to be blithe about this is not to care about the quality of the
code you produce. If you don't mind giving broken code to other members of
your team, or taking up QA's time finding bugs you could have found
yourself, or fixing one bug by introducing three more, then by all means
don't unit test.

 

[Christopher Benson-Manica]

Kabutz also gives Java developers a hard time for not unit testing. He
argues that it's a major problem and that few Java developers do it.
I'm curious: Has anyone gotten into big trouble for not unit testing?
Is it a major source of bugs in your experience? It's not a big
problem among people I talk to -- a limited sample.

Failure to unit test does not *cause* bugs, it prevents you from
locating preexisting bugs. Unit tests, combined with automated
software to run and verify them regularly, is pretty much the only
sensible way to protect the integrity of any complex project with a
lot of moving parts. Anyone not unit testing is probably wasting time
and money.