3 ms·
You're talking to the wrong people. I worked for a company that made an FDA approved diagnostic device. And to be clear, for the condition it targeted, an inc
by x0x0 11y ago
You're talking to the wrong people.
I worked for a company that made an FDA approved diagnostic device. And to be clear, for the condition it targeted, an incorrect diagnosis would kill. The approval was slow, expensive, and cumbersome. I absolutely support it. Consider the average code quality you see with every piece of software you touch. Hell, even apple can't update their iphones -- with very few models to test -- without killing wireless on some of them. The FDA required that your code was tested so that given certain inputs, it produced correct outputs every single time, and documentation to that effect.
I wish we could speed the process up, but I think it's the best alternative we have going.
edit: this was my first serious dev job. They didn't use source control. "source control" was a random computer holding the master copy; after a month or two of development, you'd spend a couple days merging your code into the master copy then copy the merged codebase to your desktop. All 8 devs did this. There were wild merge problems, as you can imagine with that much divergence. "History tracking" was copying the entire directory structure to a series of labeled directories.
There were two ways to license the machines: one for human testing (with fda approval), and one for non-human testing. The latter got releases every 3-6 mos. One at least one occasion, code was shipped so broken that it conclusively proved it had never been successfully run, not even once. The "deploy" process was to copy code from the master server, hit build in visual studio, and burn that to cds.
Automated tests? What are those? Test suites were run instructions written in a spiral notebook. (To be fair, it's hard to work with bio samples.)
I wrote a bunch of code that basically mocked the device by installed a special driver that replayed saved data files. I wrote this on my own time so I could occasionally work from home without lugging a giant contaminated machine back and forth. I shared it with coworkers and it eventually made its way to the testing lab on the other side of the country without my knowledge. When I quit, I deleted all source code. It turns out they hadn't kept a copy of this driver and frantically contacted me several months after I left when an embedded system upgrade broke it.
Many of these are symptoms of a company run by bio scientists who viewed engineering as a cost center and barely even a real career. There are lots of companies like this.
- tolmasky 11y agoI think its unfair to suggest that the reason iPhones have horrible code quality is because they don't go through some approval process. They don't have good code quality because, sadly, they don't need it. AAPL's market cap will show you that. BECAUSE iPhones aren't mission critical, BECAUSE they won't (directly?) kill anyone, they can get by with poor code quality. That market, for whatever reason, favors shiny over reliability. For an even better example: take iOS game. Those things have a shelf life of a few months, it would make no sense to make sure those things are battle tested.
- fnordfnordfnord 11y ago>for the condition it targeted, an incorrect diagnosis would kill. But that's not always the case, it's not even the average case. Where there is much lower risk, there should be much lower barrier to entry. Treating every medical device as if it were a likely Therac-25 is not even remotely a good solution, and in some of these cases the lack of approved medical equipment is directly contributing to many peoples' untimely deaths, and to even more peoples' poor-health and/or poor quality of life.