I
had an intersting hallway discussion with a co-worker last night about unit
testing and follwoing coding conventions. The readers digest version is
that he is against both of them unless he happens to like them. (Why didn't
the get him durring the layoffs? Oh yea, he's a team lead...). His defenses
are that (a) he doesn't have time to write them and (b) be tests his code
when he writes it. The problem with (a) is that he tops the foosball stats
with games played. The problem with (b) is that it is a manual process,
and he claims that he doesn't have the problem of unintended consequences
because he "takes the time to understand his code." So when confronted with
the argument of change of code ownership (which happens here alot, but not
with him yet) he says "well then the developer should take the time to understand
the code before he changes them." Holy Concieted CMM Level 0 Heroic Effort
Batman! That is practically a profession of faith against repeatable engineering
process, equvilent in value to the typical high school hackers, who he took
the time to slander. I wish I could remember exactly what he said because
it was so derogitory to people who wern't as good as he was (apparently he
never took the sensitivity training that our ex-VP said he needed in his
annual review). This discussion occured while he was packing up his laptop
and heading home so it ended with him in a huff leaving.
The
irony of this is that this morning I found a perfect example of how unit
testing protects against the law of unintended consequences, which he says
"good" developers never do. A unit test that I do involving schema validation
was breaking. Not only was I fixing the coding conventions in those files
but our IT/SCM/Build/Developer guy (layoffs do wierd things to job responsibilities...)
was upgrading the tools we use used to build and such (being between release
and such) including Xerces up to 2.2.1. Unit tests to the rescue! First
I reverted all my edited files, still breakes. Then I use older version
of Xerces, still breaks, even the version I had before the upgrades. After
some head scratching I descide to revert the whole build tree to the last
known good point and run the unit test. It works! (I would have been screaming
if it wasn't because that shows there is a SCM hole). So I sync one commit
list at a time, and it turns out the point it breaks is when... not my code
changed, not when Xerces was upgraded, before both of those even happened.
It occured when Xalan was upgraded. It turns out that 2.4.1 ships with
Xerces 2.2.0, which has a schema realted bug in it. The way the tools tree
was set up the jar loading was taking the xerces jar from xalan ($#@&ing
manifest files) rather than what the classpath said. Because of the Automated
Unit Tests I was able to narrow down the breakage to a single checkin, and
then the "Ah-Ha!" moment came much easier. With the reliable test it took
me an hour, but wihtout it I would have beens scratching my head all day
over waiting for that "Ah-Ha" to occur. not knowing where
the breakage really started. And it wasn't that a bad developer was being
a code cowboy either, it was that law of unintended consequences striking
again when a seemingly innocent change to the system wasn't so innocent.
IMHO accepting and embracing processes like unit testing is what
seperates a Software Engineer from a simple developer or programmer. There
is a difference.