Hacker News Reader

Comment by HeyLaughingBoy | Hacker News Reader

There's a couple of lines of code I wrote in a medical instrument that as far as I'm concerned are a dirty hack. Now, it's a documented dirty hack -- my boss called me into his office to laugh at the comment I wrote about it being the only way to accomplish what I needed due to the stupidity of the library I had to use -- but it's a dirty hack nonetheless.

The device has been performing admirably (as far as I know) for over 12 years in the field with no issues due to those few lines of code.

Hacks are everywhere in engineering. As long as the analysis behind it is rigorous and the hack is provably correct, I'm OK with it.

View on HN

I realize I'm over-defining a silly term, but I'd consider that a "hack", not a dirty hack.

You understood exactly what was going on and were wholly confident it would be reliable. And more to the point, you wouldn't have counted it as a mark against the product's reliability.

That really depends on the hack. Maybe it's fragile because it is building based on a bug, and if the library changes, the code will have to be updated. Or perhaps it's there based on bad behavior of a chip and a hardware update could change the nature of the issue (say, it relies on a particular instruction that's generated by the particular compiler in use to happen just before the code in question).

A hack could be completely reliable (for the same hardware, library versions, and compiler), but still be a "dirty hack". And whether a hack is "dirty" is very subjective and, IMO, based more on how obvious the fix is (e.g. radians -> degrees -> function -> back to radians because the library documentation is wrong is less bad than a non-obvious hack like multiplying by 1 or something to avoid a compiler codegen bug because of a hardware bug).

I think this horse has been thoroughly beaten, so I'll leave it here.

While a well documented hack is OK, system, by design, shouldn't need or be built around hacks.MAX nose dive issue was a hack to counter the dive which proved fatal.

But maybe you shouldn't be using a "stupid" library in a medical device?

Sure. I should just have taken 6 months off to write my own!

That's often times not an option. [Hypothetical] Just because I don't like the sensitivity of the airbag deployment sensor in the new Acura I'm designing doesn't mean I have the authority to switch it out. I can complain about it to management, but at the end of the day all I can do is modulate the signal going into to make it within industry-level safety specs.

Reply on news.ycombinator.com