Code correctness, and testing strategies

[Matthew Woodcraft]

David  <wizzardx at gmail.com> wrote:
> Might be a difference in project size/complexity then, rather than
> company size. Most of my works projects are fairly small (a few
> thousand lines each), very modular, and each is usually written and
> maintained by one developer. A lot of the programs will be installed
> together on a single server, but their boundaries are very clearly
> defined.

> Personally I've had to do very little bug fixing and maintenance.
> Thorough testing of all my changes before they go into production
> means that I've caught 99% of the problems, and there is very little
> to fix later.

> That's why I'm surprised to hear that such a huge amount of time is
> spent on testing maintenance, and why the other posters make such a
> big deal about unit tests.

> I'm not a genius programmer, so it must be that I'm lucky to work on
> smaller projects most of the time.

This is close to my experience. One lesson we might draw is that
there's an advantage to structuring your work as multiple small
projects whenever possible, even if making one big project seems more
natural.

I should think everyone would be happy with a bug-coping strategy of
"don't write the bugs in the first place", if at all possible. My guess
is that the main part of the 'small project' advantage is that all
changes can be written or reviewed by someone who is decently familiar
with the whole program.

That does suggest that if programmers do find that they're spending
more than half of their time fighting bugs, it might be worthwhile to
invest time in having more people become very familiar with the
existing code.

-M-