Radley Balko | September 5, 2007
Under orders from the New Jersey State Supreme court, the Draeger company was forced to turn over the source code for its AlcoTest 7110 breath tester, used to determine if motorists are driving drunk. Manufacturers of the devices have been refuses for years to turn over source code, saying it's proprietary. Consequently, many judges have been tossing DUI convictions, correctly determining that if a machine is going to determine guilt or innocence in these cases, a defendant has the right to investigate the methods, algorithms, and accuracy of the machines.
DUI attorney Lawrence Taylor looks at some of the more interesting findings in one tech company's analysis of the AlcoTest 7110 code.
Help Reason celebrate its next 40 years. Donate Now!
Try Reason's award-winning print edition today! Your first issue is FREE if you are not completely satisfied.
DUI attorney Lawrence Taylor looks at some of the more
interesting findings in one tech company's analysis of the AlcoTest
7110 code.
Afterwards, Taylor employed a spin-move to elude the baliff and
sacked the opposing attorney for a seven yard loss.
Anyone who has been or is a programmer knows that the vast
majority of programmers are terrible, lazy bums, and most code is
messy garbage.
It takes a very dedicated and skilled programmer/shop to produce
quality code.
Of course they didn't want to reveal the source code. Then anybody
who knows anything about programming could tear it to shreds.
This is why I always offer prospective employers samples of my
source code--I am proud of it and want them to see it.
After 30 years "in the industry", I am certainly suprised to
learn that there are "U.S. Industry Standards for Software
Development and Testing".
My bad!
CB
I wonder what the reaction would be if I were pulled over for DUI suspicion and I asked Officer Friendly to blow into the breath tester first -- just to set a baseline.
Was I the only one annoyed by Mr. Lawrence's statement,
The accuracy of these machines, which essentially determine a
suspect's guilt or innocence, depends upon the accuracy of the
software driving them; as the computer techs say, "Garbage in,
garbage out".
?
As I understand it "Garbage in, garbage out." does not refer to the
idea that the accuracy of a test depends on the quality of the
testing equipment, which is what Mr. lawrence means to say.
Instead, GIGO means that, the output of a complicated system will
be crap if incorrect data is input, regardless of the quality of
the system itself.
I've dealt with government code before. It's very... interesting. You just know that a whole team is assigned to produce each tiny bit of fastidious, thoroughly-documented code. Meanwhile I work in business and I code by the seat of my pants. "Documentation? Uh, yeah, I'll get on that." Heh.
cbmclean is correct. However, if, as stated in the article, they
do not have checking for strange values/baselines, this can be
"Garbage In".
For instance, if I write a program that is supposed to convert a
Farenheit temperature to Celsius, and I allow a user to enter
"dude" as the Farenheit value, that is Garbage In and can cause an
error or very strange results depending on how I am handling the
input.
It is the responsibility of the programmer to validate input as
much as possible to prevent Garbage In.
"DUI attorney Lawrence Taylor looks at some of the more
interesting findings in one tech company's analysis of the AlcoTest
7110 code.
Afterwards, Taylor employed a spin-move to elude the baliff and
sacked the opposing attorney for a seven yard loss."
Alright ... who are you and what have you done with Dan T?
Seriously. GIGO is a reference to the INPUT, not to the code. Of
course, the way around it is good error handling, and diagnostics,
which this software doesn't appear to have.
In their defense, I have never written a piece of clean, well
organized code in my life.
Dan,
It's more than that. Your posts lately are not inflamatory and
baiting. It suits you well.
I wonder what the reaction would be if I were pulled over for DUI suspicion and I asked Officer Friendly to blow into the breath tester first -- just to set a baseline.
You'd get the crap beat out of you. Then you'd be charged with
resisting arrest. Don't you know you can't disrespect your masters
like that.
/cynicism.
If I'd been the first to make the obligatory LT joke, I would've simply said that Mr. Taylor should be fully qualified to opine on the "under influence" part of DUI.
"You'd get the crap beat out of you. Then you'd be charged with
resisting arrest."
Yeah, that's about what I figured. Would serve me right for being a
smartmouth when all they are trying to do is protect the
public.
Don't they do blood-tests in America?
I mean, those breath-analyseres do have a limit in usefuless and in
Germany, if the analyser gives a warning, a blood-test has to
reinforce this warning, or else you cannot be tried in court.
A doctor friend of mine said he would never trust these machines.In med. scool he was involved with a test of them.The results were so varied to be regarded unrelible, and even showed positives after using mouthwash and some cough drops.He said if he used such shoddy methods in his practice he'd be run out of buisness.I'm also wary of a device for which you are threatened punishment for not using[driving suspentions].
I've dealt with government code before. It's very... interesting. You just know that a whole team is assigned to produce each tiny bit of fastidious, thoroughly-documented code. Meanwhile I work in business and I code by the seat of my pants. "Documentation? Uh, yeah, I'll get on that." Heh.
That's mostly true. As a libertarian I hate to admit this, but
government code tends to be of very high quality. But market
incentives are still missing, so you frequently find high quality
well documented code that doesn't meet the users needs. A quality
documented turd is still a turd.
On the other hand, you do find high quality commercial code as
well, just not as often. The reason it's not as common is because
large sectors of the market aren't demanding quality. If that
changes (I'm sure it eventually will), then you'll start seeing
much more quality commercial code.
Dan T., I'll need you to step outside of your vehicle and breathe into this tube, Sir.
None of his "problems" are any real indication of the
unreliability of the device. You can write the sloppiest, ugliest
code that ignores exceptions and says "// todo: delete this crap"
all over the place and it can still be 100% solid for the device
and application at hand. Of course, when you've got analog
interfaces like the alcohol detector, the software is almost always
going to be the least of your weaknesses.
It's good that he's got the source code, but he needs to focus on
how it, in conjunction with the detector, produces bad results more
than how ugly the code is. But, I guess juries will probably be far
more moved by how much slang appears in the code comments.
If ugly code is an indication of quality, does that mean that I can dismiss all Perl code as crap?
Rimfax, there's "ugly code" as in formatted badly/too many
comments/irregular naming conventions/and so on.
Then there's "ugly code" as in no code reuse, no encapsulation, and
other design flaws.
The first is cosmetic and makes code hard to read, but has no
bearing on its function.
The second is bad design and causes flaws, sometimes critical ones.
What if the programmers of the alcohol thingy didn't reuse code
properly, and changed the code for BAC calculation in a few places
but forgot one?
I work in a business that results in charred bodies if the
equipment does not function properly.
While I don't find innocent people sent to jail quite as bad as a
pile of charred bodies, I would think people that build
breathalyzers should follow design and verification practices
similar to the ones used in my business.
I work in a business that results in charred bodies if the equipment does not function properly.
Are you using the Therac-25?
You guys are thinking as code as a high-level system... Code
itself is a system embedded in a system, which is embedded in a
system, yada-yada-yada.
GIGO, as it is being referenced, is the coding input to producing
this modules. The garbage that they produce (which is most likely
intentionally ambiguous), creates garbage output that intentionally
sways toward a criminal conviction.
Site comments/questions:
Media Inquiries and Reprint Permissions:
(310) 367-6109
Editorial & Production Offices:
3415 S. Sepulveda Blvd.
Suite 400
Los Angeles, CA 90034
(310) 391-2245