Everyone who writes safety critical software should read this

[deadalnix]

On Wednesday, 30 October 2013 at 19:25:45 UTC, H. S. Teoh wrote:
> "This piece of code is so trivial, and so obviously, blatantly 
> correct,
> that it serves as its own proof of correctness." (Later...) 
> "What do you
> *mean* the unit tests are failing?!"
>

I have quite a lot of horror stories about this kind of code :D 
Now I do not try to argue with people coming with this, simply 
write a test. Usually you don't need to get very far : absurdly 
high volume, malformed input, contrived memory, run the thing is 
a thread and kill the thread in the middle, etc . . .

Hopefully, it is much less common for me now to have to do so.

A programming school in France, which is well known for having 
uncommon practices (but form great people at the end) do run 
every program submitted by the student in an environment with 8ko 
of RAM. The program is not expected to do its job, but to at 
least fail properly.

> Most software companies have bug trackers,

I used to work in a company with a culture strongly opposed to 
the use of such tool for some reason I still do not understand. 
At some point I simply answered to people that bugs didn't 
existed when they weren't in the bug tracker.

> For automated testing to be practical, of course, requires that 
> the
> system be designed to be tested in that way in the first place 
> -- which
> unfortunately very few programmers have been trained to do. 
> "Whaddya
> mean, make my code modular and independently testable? I've a 
> deadline
> by 12am tonight, and I don't have time for that! Just hardcode 
> the data
> into the global variables and get the product out the door 
> before the
> midnight bell strikes; who cares if this thing is testable, as 
> long as
> the customer thinks it looks like it works!"
>

My experience tells me that this pay off in matter of days. Days 
as in less than a week. Doing the hacky stuff feel like it is 
faster, but measurement says otherwise.