27 May
2023
27 May
'23
8:48 p.m.
On Thu, May 25, 2023 at 07:34:19PM -0400, Paul Koning via cctalk wrote:
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.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
On May 25, 2023, at 6:29 PM, Christian Kennedy
via cctalk <cctalk(a)classiccmp.org> wrote:
On 5/25/23 12:30, Chuck Guzis via cctalk wrote:
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." ...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.