Business, Linux, Ethics and Standards - [Was]RE: [Sussex] Yet Ano ther Windows Bug

[Trevor Marshall]

On Tuesday 06 May 2003 11:26, Geoff Teale wrote:

<lots of stuff I mostly agree with snipped>

> I've seen exactly the same more than once in this company as well.  None of
> this is really Microsoft's fault.  It's the fault of the developers
> involved.

Errr, I may just have to take issue with you here, depending on what you mean 
by "the developers".  The problem usually reduces to inadequate specification 
of requirements and/or inadequate testing against those requirements.  If the 
requirement is to design a system capable of accurately recording all sums 
(to the nearest cent) up to, say, a billion dollars then using it for larger 
sums is outside the design requirements, and it's unreasonable to expect it 
to work.  Not only that, but if the requirement is as above, and you spend a 
significant amount of extra effort making your product handle larger amounts 
then you are effectively wasting that effort as it does not (directly) help 
you to meet the requirements.

Of course, in the free software world, writing software to scratch your own 
itch in your own time you can do what you want.

>  Trouble is, people have this mental block about computers,
> anything a computer says is gospel, 

There used to be a twist on the old GIGO (garbage in, garbage out) which 
added 'but, having been through the computer this garbage is now infallible'.

> and this of course, is why we shold
> have independent qualifications for programmers and those qualifications
> should include a course of Assembly programming and an exam on computer
> science. The further away we get from the issues the less we understand
> them.  It's fine to use high level languages and tools, they help, but you
> can't tell what they are an aren't doing unless you know where to look.

So do you need an elec. eng. qualification so you understand how the 
transistors work, or some particle physics to understand properly how the 
semiconductors are made?  I think not.  But you do need to have accurate 
requirements, and a tracable means of testing your code to demonstrate that 
you've met them. As for the high-level / low level languages stuff, you 
should choose the language most appropriate for the problem domain.  I'm not 
going to attempt to manipulate registers directly in 
[Perl|PHP|Python|Ruby|VB], but I'm unlikely to bother to write a script to 
manipulate some database data in x86 assembler.  (That may be because I don't 
actually know much x86 assembler, although I do know a few others, mostly 
obsolete now)

You might also think on this: if you meet all the customers requirements, 
pass all the tests agreed with the customer and the software doesn't do what 
the customer wants,  who's fault should that be?

-- 
Trevor Marshall