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 <[EMAIL PROTECTED]> ----- From: Mark Phillips <[EMAIL PROTECTED]> Subject: Re: Response to "In house software guidelines" Date: Wed, 4 Feb 2004 13:50:01 -0800 To: [EMAIL PROTECTED] 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
