If most people posted this up I'd think it was BS - but I've seen enough
from you to be pretty sure it isn't. We've had all sorts of people in
to advise us on processes, and none of them has come up with anything
that would be a real change from the way we've always written software:
Engage brain, double check it, then test it to death. About the only
thing that's changed is a formal code review - and I know that does miss
things.
I'd be fascinated to know what you are doing. Is it documented anywhere?
SEI. (
http://www.sei.cmu.edu/)
Of course, it's not been the case everywhere I've worked. But
when the contract with the final user specifies contractual
penalties for down time, management is motivated to make it
work.
The key, or one of them, is the feedback. You get an error in
the field; you ask "what could we have done differently so that
it would have been caught in code review?" Sometimes, it's a
question of simply taking code review a bit more seriously, and
checking for "obvious" things, like uninitialized variables.
Other times, it's a question of writing simpler code (although
if the code is too complicated for the reviewers to be 100% sure
that it works, it needs to be reworked to be simpler). Or are
you forgetting to consider the border cases---make it a point
for a while to list them explicitly, and verify them. I've also
found writing things out to be helpful---somehow, what
"obviously works" ends up having flaws when you try to explain
in writing why you're sure it works. The point is, of course,
that someone looking at your code should be rapidly convinced
that it is correct. Not that he doesn't see any errors, but
that he can see clearly that there aren't any.
