Hacker News Reader

> 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.

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.

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).

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.

> 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.

Well, there is some merit to it, isn't there? You could make a mistake when splitting up that function, like with any other change you make.

The software I write runs on the telephone network, where downtime not only costs us thousands of dollars of unbillable time, but penalties our company has to pay to the Monopolistic Phone Company for violating our SLAs. Even a simple change (like zeroing out a few variables in a certain condition---nothing critical to the call path but would make billing much easier for us) can take months to work its way through the process of two companies (six months so far and still waiting for this patch to be deployed).

Yes, it sucks. Then again, I'd rather not cost our company more than my yearly salary for a simple mistske.

A small error, which, if I remember correctly, although it's not mentioned in this account, was in a tiny change that was not tested as fully as it should have been, took down AT&T's long distance network in 1990, back when it probably still carried most of the nation's long distance calls: http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/att_collaps...

I have same experience. I was assigned to account - big oil company, where one mistake like typo in port or source/dest. IP had a huge impact. Even mistake has been fixed within minutes.

You wouldn't believe how poor IT processes are implemented over such critical infrastructure (oil rigs, infrastructure handling wall-street financial transaction etc) in outsourcing companies. I am not talking how big mess is in configuration and related documentation.

You don't really need to change that 500 lines of code with a shorter version on a rover trekking around at Mars.

But whatever you do change, you really want to make sure it is worth the risk, screwing that up has greater consequences than asking someone to restart the web server.

Okay, it can be replaced by three 80 line functions. Where are the unit tests? What's the difference in object size after the code's been compiled? As it's been broken up into three separate function calls, how much more of the stack is it taking up? Does your code rely on excessively complex tricks which would make it more difficult for someone 20 years down the road to understand? What benefit does your change make to the overall process?

With Source Code Management, what you're doing is making sure someone owns the process of ensuring well-documented , well-verified code is what becomes part of a system that will be used for the next 40+ years. Those big enterprise systems you deride have been proven they can handle decades of use, can you say the same of your modern VC system?

The most expensive outage I ever witnessed was due to such an innocuous cosmetic change. In general, I have never been able to notice a clear correlation between what seems likely to fail and what actually fails, therefore I'm fine with restricting update on working code however ugly it is.

That's just the usual procedure of any large git based project.

NASA didn't have a modern VC system by then, it's perfectly reasonable that they'd implement the procedure by hand.