On Friday, 1 November 2013 at 13:52:01 UTC, Wyatt wrote:
On Thursday, 31 October 2013 at 21:36:11 UTC, eles wrote:
Yeah, maybe is a corporation culture to avoid the term "bug",
but we always use the term "change request". Maybe it has a
better image :)
Lately, I've instead been reframing my thinking toward parity
with Dijkstra. EWD1036 [0] is particularly relevant to this
topic:
"We could, for instance, begin with cleaning up our language by
no longer calling a bug a bug but by calling it an error. It is
much more honest because it squarely puts the blame where it
belongs, viz. with the programmer who made the error. The
animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as
it disguises that the error is the programmer's own creation.
The nice thing of this simple change of vocabulary is that it
has such a profound effect: while, before, a program with only
one bug used to be 'almost correct', afterwards a program with
an error is just 'wrong' (because in error)."
As a bonus, my experience is it more readily encourages
management types to accept that fixing them is important.
Normally, it is assumed that passing the tests proves that
specifications are accomplished, so the software is perfect.
This, of course, if the tests themselves would be correct 100%
and *really* extensive.
Again from EWD1036:
"Besides the notion of productivity, also that of quality
control continues to be distorted by the reassuring illusion
that what works with other devices works with programs as well.
It is now two decades since it was pointed out that program
testing may convincingly demonstrate the presence of bugs, but
can never demonstrate their absence. After quoting this
well-publicized remark devoutly, the software engineer returns
to the order of the day and continues to refine his testing
strategies, just like the alchemist of yore, who continued to
refine his chrysocosmic purifications."
This passage comes just after he laments that "software
engineer" had been diluted so thoroughly as to be meaningless.
(I'd greatly appreciate if this term could be reclaimed,
honestly. Experience has shown me quite clearly that not every
programmer is an engineer.)
-Wyatt
[0]
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
No, not every programmer is an engineer. But not every programmer
writes safety critical code. If Firefox crashes, nobody dies as a
consequence (hopefully!).
