Oliver said:
The comment was something along the lines of "This has to be done this
way, because method 'foo' is assumes 'bar' in another file".
Of course, someone changed method foo so that it no longer assumes
bar, but never saw this comment (probably never even opened the file that
contained this comment), and so it was never updated.
Really, I don't think any one particular programmer is to be blamed
(or accused of incompetence) in this scenario. The error just sort of
"evolved" out of successive refactoring of this very large application.
That's an interesting scenario. I agree that it would be wrong to talk of
"incompetence", but I wouldn't go so far as to say that there was no blame
involved. It's impossible (for me, here) to say /who/ should be blamed, but
I'm fairly sure that a close look would show that /someone/, not necessarily
any single programmer (it could be a management failing, for instance, or the
result of bad company culture), would be shown not to be doing a good job.
The real problem here is that either:
a) the dependency should not have been introduced
or:
b) if the dependency was unavoidable, then the comment was in the wrong
place.
I.e. it was either failing of design, or of communication -- in either case it
was an actual /failure/, not "just one of those things".
Ideally, the programmer(s) who introduced the dependency should have been able
to change the stuff that it depended on in such a way as to remove the need for
it (some sort of refactoring). Of course that might have been impossible for
technical reasons, or it may have been impractical for project management
reasons (the "other" code was already frozen, perhaps). But notice that if
there was a technical solution that was not taken for "non-technical" reasons,
then that is clearly a failure of management (in the wide sense, including the
programmers as well as the actual Managers).
If a correct coding change was not introduced (for whatever reason), then
putting the explanatory comment in the dependent code was almost exactly the
wrong thing to do (not quite, because even a mis-positioned comment /might/ be
useful). Properly, the comment should have been added to the code with the
hidden dependent: "don't change this without corresponding modifications to
xxxx". More generally, the people who "owned" the dependent code should have
talked to the people who owned the other code (they could be the same people of
course, but in that case I don't see a problem with putting the comment where
it should have been). The owners of the "other" code could have recorded the
dependency in their design documents (if any -- I'm not a big fan of them
myself); in their collective memory; or as a comment in the development branch
of the code in question (assuming the release branch was frozen).
So I'd say there was definitely a blameworthy failure somewhere. It might be
no big deal (you didn't say how serious the consequences of the mixup were),
possibly not even worth as much discussion as I've just typed in. But if the
consequences were severe, or if they could have been severe, then I'd say that
the failure was also severe, and -- although throwing words like "blame" about
might be counterproductive -- there would still be an obvious problem in the
dev group's working practises that should be identified and (if possible)
corrected.
-- chris
