Matt said:
The code is quite often wrong.
Of course, "quite often" is not an exact quantification, but I have not
worked anywhere where the code was what I'd call "often wrong," nor would I.
The problem I find is that people THINK
the code tells you what it is doing. Unfortunately, without some
background in
what the code was intended to do (the problem we are solving) it is
difficult to
know if the code is right or not.
Again, that's where tests come in.
I've had this discussion with people before. You are right, in that
unit tests and such are useful.
For me, they're essential. I do Test-Driven Development (TDD), where I write
no new code without a failing test. In other words, I don't fix a bug until
I have an automated test that exposes the bug. And I don't write a new
feature until I have a test that proves that feature is missing.
For any large scale system, however, unit tests are
often more optimistic than you would like to think. Simple test coverage
doesn't
show up problems that occur over periods of time in real-time systems, for
example. And the chances of you covering all possible data irregularities
is .. to
be kind.. unlikely.
You're talking about a different kind of testing than I am. TDD, it is often
said, isn't about testing. I think that's somewhat overboard, but it has a
kernel of truth. You're not pretending to be a QAer, whereby you verify that
the code is 100% bug-free. Rather, you're expressing in tests what the code
is supposed to do. It's a way of designing and documenting. It does have the
benefit of reducing bugs, but that's not its purpose, until you start
refactoring (improving the design without changing its functionality).
You make a good case about the documentation not being updated. This is
a serious problem and one that should be considered when writing the code
in the first place. A change to the code that is not reflected in a change
to
the documentation is a worthless change.
I almost agree, except that I replace "documentation" with "test." Code that
doesn't have tests is worthless, IMO.
Yeah, I know. But that's not the documentation's fault. That's the
fault of whoever didn't update it, or his/her manager. The fact that
documentation is
rarely done right doesn't make it less valuable. That's like saying code
is worthless
because every non-trivial application has bugs.
But coding is not "rarely done right," whereas documentation is. In a
perfect world, documentation might be the answer to improving the quality of
code. In this world, TDD (IMO) is the best way to achieve this.
I've had good and bad experiences with docs. I'm not really disagreeing
with you, there's never time allocated to do documentation right. Maybe we
can
change that, however.
The trouble is that documentation quality has been bemoaned since Day 1, and
nothing seems to be able to improve it. The reason (I feel) tests are better
is that you can automatically prove whether or not they document the code.
Thanks for the discussion, its been valuable.
Same here, Matt. You can probably tell I'm a bit of a fanatic about TDD. In
fact, I just got back from a Bay Area XP meeting, where we spent four hours
talking about this stuff.
