4 ms·

> Oh, you noticed that this 500 line copy paste function could be replaced by three 80 line functions? Sorry buddy, before you can change this you have to fill

by Kirth 10y ago

> Oh, you noticed that this 500 line copy paste function could be replaced by three 80 line functions? Sorry buddy, before you can change this you have to fill out this form in triplicate and what for a decision from three middle managers. Maybe we can fit this change in the next release, but don't get your hopes up. Because as it turns out, writing mission critical, one-off software is difficult. Touching a piece of code that's firmly embedded in the system could have serious consequences. (Of course, it shouldn't; any mistakes should be caught by testing but we all know how that goes.) These are rules for a place that makes massive, expensive and dangerous things, not a webdev shop.

kidmenot 10y ago
Also, the fact that human lives might be at stake makes the whole system life-critical rather than just mission-critical. Machines can be rebuilt no matter how expensive they are, but human lives are gone for good. Having extremely rigid policies about accepting changes doesn't sound that crazy to me. What kind of serious professional would want to change the code of a life-critical system the same way they change that of a CRUD webapp? That's a kind of software development where saying "oh, human lives at risk here, I'll be super-careful" doesn't quite cut it.
informatimago 10y ago
Until somebody tries to drive a surgical robot using your webdev javascript components... And don't dismiss the idea: they do use Microsoft Windows in surgical robots (including eye laser robots, which is why I'll never have it).
- notalaser 10y ago
  I've worked on such devices before. I don't know how it goes for the surgical robots you mentioned, but in general, this can be made in a sane manner. Um, using a Windows application for the UI. I wouldn't be partial to operating a surgical level through a web interface, but only because of the unpleasant UI latency and the inconvenience of doing anything that's not HTTP from it. The way this is (normally/sanely) done is that the control code for the robot runs on its own CPU and does all the failsafe, real-time-contrained stuff. The robot's control code doesn't receive control-level instructions, but messages of the form "move to position X,Y,Z" or "move N units on axis Y" (which it validates and, ideally, against which it also has mechanical limits, i.e. the mechanism itself cannot move to an invalid or dangerous position). The application that gets user input and sends these messages doesn't need to be NASA-level stuff as long as it runs on another CPU. In more recent years, this CPU and the one that runs Windows and the nice interface have been starting to come in the same box (and, more recently, even on the same die), but until not so long ago these were usually separate boxes, connected through serial, USB or Ethernet. This is still common, I've finished the firmware for one such device just a few months ago. I don't know if you can actually pass through FDA's process with a robot that's running Windows, but frankly, I wouldn't try it. But there's nothing inherently unsafe in running the UI on general-purpose software and hardware, as long as the control code is robust enough in its validation and the interface between the two is correctly designed.

by Kirth 10y ago

kidmenot 10y ago

Also, the fact that human lives might be at stake makes the whole system life-critical rather than just mission-critical. Machines can be rebuilt no matter how expensive they are, but human lives are gone for good. Having extremely rigid policies about accepting changes doesn't sound that crazy to me. What kind of serious professional would want to change the code of a life-critical system the same way they change that of a CRUD webapp? That's a kind of software development where saying "oh, human lives at risk here, I'll be super-careful" doesn't quite cut it.

informatimago 10y ago

Until somebody tries to drive a surgical robot using your webdev javascript components... And don't dismiss the idea: they do use Microsoft Windows in surgical robots (including eye laser robots, which is why I'll never have it).

notalaser 10y ago
I've worked on such devices before. I don't know how it goes for the surgical robots you mentioned, but in general, this can be made in a sane manner. Um, using a Windows application for the UI. I wouldn't be partial to operating a surgical level through a web interface, but only because of the unpleasant UI latency and the inconvenience of doing anything that's not HTTP from it. The way this is (normally/sanely) done is that the control code for the robot runs on its own CPU and does all the failsafe, real-time-contrained stuff. The robot's control code doesn't receive control-level instructions, but messages of the form "move to position X,Y,Z" or "move N units on axis Y" (which it validates and, ideally, against which it also has mechanical limits, i.e. the mechanism itself cannot move to an invalid or dangerous position). The application that gets user input and sends these messages doesn't need to be NASA-level stuff as long as it runs on another CPU. In more recent years, this CPU and the one that runs Windows and the nice interface have been starting to come in the same box (and, more recently, even on the same die), but until not so long ago these were usually separate boxes, connected through serial, USB or Ethernet. This is still common, I've finished the firmware for one such device just a few months ago. I don't know if you can actually pass through FDA's process with a robot that's running Windows, but frankly, I wouldn't try it. But there's nothing inherently unsafe in running the UI on general-purpose software and hardware, as long as the control code is robust enough in its validation and the interface between the two is correctly designed.