(forw) Re: Response to "In house software guidelines"
Greetings,
on the international MedPhys mailinglist there is a
discussion going on about guidelines for in-house software
development. Ira Kalet who is a respectable member of the
MedPhys community, made some very good points. I thought
his posting might be interesting for some of you as well.
(BTW: Does anybody know more about the AMIA open source
working group mentioned in his posting? For some reasons
I cannot reach their webpages.)
Best regards - Juergen
----- Forwarded message from Mark Phillips <xxx@xxxxx.xxx> -----
From: Mark Phillips <xxx@xxxxx.xxx>
Subject: Re: Response to "In house software guidelines"
Date: Wed, 4 Feb 2004 13:50:01 -0800
To: MEDPHYS@LISTS.WAYNE.EDU
I am forwarding this reponse to Shlomo Shalev's post by Ira Kalet. Ira
has been out of the office due to illness and asked me to post this for him:
From Ira Kalet:
1. Most commercial software is "warmware" by Shlomo's definition, just
that the "author" is some company that you hope and pray will continue
to respond to bug reports and improvement requests (and stay in
business). The fact that a company sells a product has no implications
regarding its being up to "professional standards". There was a lot of
resistance to FDA regulation of RTP systems initially, but all they were
really doing is trying to insure some kind of baseline of good software
engineering practice in a commercial business that was pretty chaotic.
At least with in-house warmware, you have some local control. This is
the principal driving force behind the Open Source movement.
2. I have not read Shlomo's guidelines recently, but we had many
discussions in the medical physics community back in the 1980's when NCI
was more willing to fund such projects. Most such guidelines and
discussion about them were focused on documentation practices and on
transcriptions of trivial or misunderstood ideas in software practice.
It had no impact on software quality. Documenting a junkpile does not
turn it into a fine piece of art. Claiming that something is modular
because it has a bunch of class definitions instead of FORTRAN COMMON
blocks doesn't make it so.
3. There is now a very big movement for open source software in
medicine, and the American Medical Informatics Association
(www.amia.org) has recently established an open source working group. If
AAPM were seriously interested in software (in my opinion it never has
been, leading me to finally drop my membership), it might be well for it
to do the same and for such working groups to be in touch. It has
always dismayed me how narrowly medical physics people view their
involvement with computers as if what we do is so specialised that no
decades of research in Computer Science or Software Engineering, or
other medical software domains has anything to contribute to us.
4. Here is my own opinion, based on 42 years of involvement with
computer programming, 26 years in medical physics (mostly with software
projects), and 20 years in medical informatics and computer science
(including teaching both graduate and undergraduate CS and medical
informatics courses on programming and artificial intelligence):
There is no mechanical substitute for a deep understanding of the
principles of design. Software design is like other crafts - some few
are great craftsmen, most are amateurs. If you want to be more than an
amateur, you have a lot of reading to do. In particular, look at great
programming examples, and look at the code. Read articles about
software design, not standards or guidelines.
One of the best books in this direction that I know of is Peter Norvig's
Paradigms of Artificial Intelligence Programming. I am working on a
kind of similar book which will be on biomedical programming, including
an extensive treatment of the Prism RTP system project I have led the
last 15 years (and its predecessors). If anyone has created a truly
great piece of code, and would like me to consider including something
about it in the book, get in touch.
Ira Kalet
Reply to: