Last night, I attended a meeting of MDG (Medical Development Group), an organization for people that work with Medical Devices. This particular meeting was devoted to software development issues within the Medical Device community: http://www.meddevgroup.org/med_soft_sig.htm . Attending their meeting, I noticed there are many crossover issues that they have and that we also talk about within the laboratory informatics area. They’re talking about using open source to do development, for example.
One significant difference, though, is they do primarily speak of software development for custom software and, thus, also speak quite often of development methodology. Their favorite methodology appears to be that of Agile software development: http://en.wikipedia.org/wiki/Agile_software_development . Very specifically, one issue they focus on the issue of rating the risk throughout the software based on the risk involved in the step. We talk a little about this kind of risk management and then we don’t actually do this. I find that we focus our testing more based on software complexity than we do the risk of the user’s work.
But back to the general topic of software development, what I find fascinating about this is that, even though our laboratory informatics industry does still have pockets of software development, I never hear those of us doing custom development, even those using open source, discussing the SDLC (Software Development Lifecycle) methodologies.
Some of you might argue that they’re interested because medical device software development is so much more serious and more straightforward than that of other types of software development. That’s not actually true. For one, not all medical devices carry great risk. They themselves point out that, regardless the risk, all their software “should” follow the same path, just possibly with the heaviest focus on the steps for the riskiest devices. And they have the same problems anyone else does getting their companies to take the process seriously and give them sufficient time for it. Also, they do this even when they’re in the research stage. After all, you can’t prove control of your software if you don’t start your methodology early. Also, there are some questions they have that I feel are fairly settled in the Pharm/Biotech area. So, in some respects, such as testing COTS, we are actually ahead of them.
At the workshop I ran at SmartLabs Exchange 2009 http://www.smartlab.co.uk/ , I had a variety of companies from various industries. We were heavy on Pharm/Biotech, but leaning more toward R&D than QC. In an exercise I presented, we came up with a similar outcome. The exercise I created focused more on our COTS systems than on custom development, but the outcome of our exercise was that we need the same steps regardless whether it’s a regulated system or not, with these two differences:
- Some steps will be done a certain way for a regulated system. For example, the way we document our testing is sometimes specific when the system is regulated.
- The steps will be managed entirely different for a large project than a small project.
Although I specifically created the exercise to bring out these types of issues, I did not tell people the outcome I expected. I really did let them come up with this themselves. So, among people that had experience in a variety of situations, they came up with this fairly independent of me (I tried not to hint or push them in their outcome). Of around 15-25 people (I remember a full table, but not how big it was), only one person maintained that regulated system projects were entirely different than unregulated ones.
As such, I’m wondering whether the people still doing custom development should be dropping the word “Agile” in their conversations. For all the “open source” conversations I hear, I don’t think I’ve once heard them mention their development methodology. Now, I want to say that I don’t think Agile is the be-all-end-all of methodologies, but it is a choice. And the fact that I hear no talk of methodologies had made me realize that that’s the problem. It doesn’t have to be Agile, but it has to be something. As usual, we seem to be behind everyone else in our software development strategies. Someone will likely write to me and use the usual excuse, “It’s different because it’s LIMS or ELN and it’s not really software so the rules don’t apply to us.” As usual, I’ll laugh, but sadly.