Substandard software in medical devices?

(As a computer programmer I'm going to comment on this. I've been programming for 35+ years and I've worked in a variety of companies from Fortune 500s to small 1 man operations. My comments are based on my experience and illustrate how things could possibly go wrong.)

Background of the development process

Medical device and other companies sometimes try to develop software overseas. There are a few good software developers in say, India, I've used their software. But many of them lack attention to detail and polish, and this could actually kill someone, say, if they are using a computer to deliver morphine via IV. The problem here is not necessarily the developers, but the US management teams. Managers are often clueless about how development works and the development cycle. They are given a fixed budget and must release the software as soon as the date arrives or the budget is used up. This is one of the best ways to develop poor software.


The development cycle for a piece of software is roughly like this:

1. Work with the customer to determine what the software needs to do. 
2. Design the software, and go over details with the customer once again. Keep in mind the customer contact the programmer deals with is usually NOT a computer person nor a programmer!. They might be an executive who doesn't even know how to use computers, or, as in my case, a marketing person who doesn't understand the importance of data consistency. 
3. Develop a test plan. 
4. Write the software.
5. Begin testing, looking for bugs and generally trying to break the software.
6. If a bug is found during testing add more code and go back to step 5.

The testing phase, which includes finding bugs and removing them, typically takes up 40% of the whole development process. Because computers are so complex, and there are so many unknown and unexpected variables, it is not humanly possible to write a flawless test plan from the beginning. So as new test ideas emerge during the testing phase, more code is added, the test plan is changed to reflect the new test case, and costs increase. Software development managers who are familiar with the dev process often have another 30-50% additional secret budget in reserve for cases like this. A software dev manager without access to an additional budget will slow the company down and possibly close it due to financial difficulties. Programmers are wise to avoid a  manager like this and programmer applicants should ask the manager open-ended questions to ferret out their experience with software development.


Software development often goes over budget and past the original deadline because of finding and fixing previously unknown bugs.

On to the article

The kind of software developers that device manufactures hire also leaves a lot to be desired. They tend to rely on externals, mostly unvetted, who are hired on short-term contracts and have no stake in the future of the product. They are typically hired not for their software development experience, but for how they seem on paper. 

This is just more evidence of either an inexperienced software development manager or clueless executives who are hiring contract programmers. To get good at programming, the programmer needs years of programming experience not just with the languages in question (and they could be using 4+ languages for a single project!) but with the system in question too.

Using a programmer experienced in the needed languages, and retaining programmers who know the specific software, will cost the company less in the long run, because it means the software is done well up front, leading to fewer lawsuits and recalls for the company that issued the software-driven device. Common mistakes for executives inexperienced with software development leads to short-term profits, but long term problems. Rewriting code is VERY expensive because it takes time for a new developer who has never seen the code before to just figure out what it's doing in the first place. Then they have to figure out what it's supposed to do, and then make the code do what it was supposed to in the first place.

The article is a good read and what it describes does happen. But when a person's life is at stake, if it happens once that's one too many times. 


Sources
Skankworks. April 22, 2016.