On 2023-05-27 2:48 p.m., Alexander Schreiber via cctalk wrote:
On Thu, May 25, 2023 at 07:34:19PM -0400, Paul Koning via cctalk wrote:
On May 25, 2023, at 6:29 PM, Christian Kennedy via cctalk
<cctalk@classiccmp.org> wrote:
On 5/25/23 12:30, Chuck Guzis via cctalk wrote:
...and we still get gems like the Boeing 737MAX...
I get your point, but it's a bad example. MCAS worked precisely as specified,
and while one could have a discussion regarding if those specifications were
wrong, the logic was that a MCAS failure was indistinguishable from any other
737 trim runaway and was to be handled in the same fashion. Perhaps this is an
example of Brooks' observation that most bugs in software are in fact bugs in
specification.
I'm not sure that observation is true anymore, with the "hack it until it stops
crashing" approach to software development that seems to have been brought to us by
the PC and gaming culture.
In my work (storage servers) I would from time to time see bug reports closed by the engineer as
"works as designed". I would remind them that they are only permitted to say that if (a)
the program matches the spec, AND (b) the spec is right. I would say "if you're not able to
stand on a conference center stage and explain to an audience of 1000 customers why the spec is
right, you can't use 'works as designed'. The bug may be in the spec rather than in the code, but
it's still a bug. Fix it."
Which is why among the more cynic^Wexperienced SREs (my line of work)
we sometimes use the term "Working As Implemented" when the code behaves
exactly as written (and ofteni as specified), but still does the wrong
thing because it (usually) was written with wrong assumptions.
Kind regards,
Alex.
How do prove it with typo-graphical errors in the docs?
Ben.
