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.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
