On Sun, 29 Apr 2018 11:30:56 +0100
druck  wrote:

> On 29/04/2018 11:01, Gareth's Downstairs Computer wrote:
> > On 29/04/2018 10:14, Ahem A Rivet's Shot wrote:
> >> On Sat, 28 Apr 2018 19:43:36 +0100
> >> Gareth's Downstairs Computer
> >>  wrote:
> >>
> >>> For example, I was contracted to work on the development
> >>> of a CANBus steering mechanism which used one of the
> >>> object repository. When I wished to check the efficacy
> >>> of my proposed changes by drilling down to everything
> >>> that would be affected by the change, I was refused access
> >>> to the source of the already implemented classes.
> >>
> >>     Makes sense, code should be built to the spec of the underlying
> >> libraries and not to the implementation. If behaviour outside the spec
> >> matters it needs to be bought into the spec, and preferably tested for.
> >
> > It is lack of knowledge of the implementation that hides bugs.

 One way to create subtle and nasty bugs is to write code that
depends on the implementation rather than the spec.

> No, it's lack of testing.

 Give this man a cigar.

> There will always be a limit to how far you can drill down through the
> software stack, firmware, microcode, and hardware implementation, and an
> even bigger limit on how much of that you can really understand by
> itself, and as a complete system. The only way to know if the entire
> system behaves in the way you want it, is to test it thoroughly.

 Yep - and when you do the tests will tell you exactly what
behaviour you can count on while the spec should tell you exactly what
behaviour you should be able to count on. In an ideal world these two are
the same ... never seen it yet, but I've seen it come close.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

--- SoupGate-Win32 v1.05