Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message

[Luke Kenneth Casson Leighton]

On Fri, Aug 20, 2010 at 4:59 AM, Karsten Hilbert
<address@hidden> wrote:
> If the explanation for your rapid coding is that you dont mind too much
> about the correctness of the solution (or rather only to the degree of
> apparent correctness) I wonder whether doctors will trust our code to
> run their patients on. I am being rather cautious in my wording here.

 ah - that is not the case.  it's good that you raised it, but it's
not the case.

 what i've done is create a stepping-stone, the ultimate goal is to
get from "A to Z" but the current code has got to "C".  unless a
beginning is made, there is no way to understand whether it is
necessary to go back to B or to even determine where D is.

 the code written so far has been written with a very very specific
limitation: absolutely no database schema modifications whatsoever.
thus, in order to get a handle on what's involved and what's needed, a
small "detour" has been needed [overloading test_unit name to include
a sub-id and overloading encounters to represent the OBR-OBX hierarchy
as per HL7 specification on observational reports].

 regarding the "trust" - i can be of absolutely no assistance to you,
there, whatsoever - not to you, nor to any doctors using the code.  i
do not often use personal pronouns in project development, but in this
instance it is unavoidable.  i am "merely an assistant" - merely an
"enabler", to get some very specific features done.  you say jump,
and, as you've seen already, before you know it, the work's done
already. i realise it's unusual: that takes getting used to, that i
can in certain circumstances appear to "sublimate" code, to use an
appropriate analogy right out of chemistry 101.

 here are some ways in which the code written can be quotes trusted quotes:

 a) some unit tests are written.  lots and lots of unit tests.  there
are none right now because the project has only just begun, and those
tests which are there are part of the "development cycle".  the unit
tests then need to be reviewed, to make sure that they actually do
what they are intended to do.

 b) _you_ read the relevant specs.  there's no point in _me_ reading
them and then telling you "yes, these specs are good".

you can see that neither a nor b involves me making the decision, nor
me saying "this code can be trusted" - that's not my role to say that.
 my role can _only_ be that of an assistant / enabler.  as the
project's lead developers, it's down to you to make that decision.
now, as an experienced programmer, i happen to know what steps are
needed to be taken, such that "trust" can be given (to taking those
steps), but that trust _does_ have to be given by you, in the process
used to get from A to Z, and thus, once you say "yes i trust this code
and the process", doctors can also place _their_ trust in the code and
the process.

i did say, right at the beginning (at least i spelled it out very very
clearly to jim, privately) that unit tests _are_ going to have to be
written, and that there's absolutely no way that the code can be
trusted _until_ those unit tests are in place.

ironically, the writing and addition of unit tests - getting to the
point where the code can be proven to be correct - is going to be a
lot longer than the time taken to write the initial code, i can tell
you that right now.

l.