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

[Geoff Teale]

On Tuesday 06 May 2003 9:56 pm, Trevor Marshall wrote:
<snip>
> 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.


Sorry.. I should be clear.  The requirements for what data the product should 
handle are well defined by over 30 years of experience.  The backend of this 
application was the same mainframe and database that had been maintained 
since 1968, all the data you could pull from it (and the various formulae and 
calculations) had been established and well documented for more years than I 
have been alive, and all of the customers are intemately familiar with them. 

This product was simply a new front end to the existing app to replace an 
aging text-based interface.  The mistake in terms of Malaysian law was one 
made by our legal teams who were paid to checks on the validity of our 
software and processes in all of the major markets.  The mistake in terms of 
the functionality of Excel (with specific regard to integers exceeding 2**64) 
was our developers fault.   Other teams had routinely taken account of the 
fact that we needed to use numbers on that scale - this team simply didn't 
understand the concept that there was a limit to the size of a Visual Basic 
Long type.

> 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'.

Garbage in, Gospel Out ;-)

Silly thing is this system was Gospel In, Garbage Out.. which is _bad_.

> 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)

Well, maybe I'm overstating the case, but I do feel we need an independent 
professional qualification  like accountants or lawyers have.  The reason we 
don't have these things is because we are a relatively young industry and we 
are in short supply.  Companies will hire whatever they can get rather than 
people who know what they are doing.  The guys who screwed up in this case 
did so because they had no concept that there was a limit to the size of an 
integer defined as long in Visual Basic.  That information is in the VB 
documentation, but they'd never bothered to check it becuase they didn't know 
that such a limitation _could_ exist.  

The point I'm making is that we have no standards, no barrier to entry in the 
field of computer programming, and as a result more mistakes are made than 
necessary.  

The reason I single out assembly code as a good thing for people to be 
involved with is this:  Assembly forces you to deal with the fundementals of 
_your_ job.  I don't suggest we code commercial systems in Assembly code, but 
there is no better primer that a short sharp shock of bare metal programming.

Teach people GNU MDK for a few months and then tackle C++, Java, VB whatever.  
Don't teach people a high level language and expect them to cope when things 
go wrong.  

Is it really so contraversial to suggets that you'll learn more about good 
system development from Knuth's "Art of Computer Programming" than you will 
from "Java in 21 days"?

This isn't about snobbery - I actively encourage the use of high level 
languages - I'm about to become a full-time Python developer!  I just think 
that a lot of time an money is wasted on an infinite number of monkeys when 
we could shortcut it all by employing a smaller number of playwrights up 
front.

> 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?

Thats the fault of both the customers and the people who specified the system.  
Agile development techniques can help minimise this kind of problem by 
constant re-analysis, automated testing and short release cycles.  If you try 
and specifiy it all upfront, then build it, then test it, you're going to get 
things wrong on a humungous scale.

It's not fair to point the finger at a customer and say "you didn't explain 
what you wanted properly", you need to manage their expectations of you, yu 
need to make them aware that you are software engineers, no Bee Keepers or 
Warehousemen or whatever it is they do, and you need very clear definitions 
and universally agreed acceptance tests. 

-- 
GJT
Free Software Foundation
tealeg at member.fsf.org