Ok,this maybe too nerdy of a topic for here but that’s why I love unit tests.
Basically I write a piece of code that gets this input and generated that output. I also make a test to verify that I get a certain output given a certain input.
Now if I spend all day futzing within that code , changing variable names, refactor and extract a large function to 10 small ones, decide to re-write all the SQL queries to linq arguments…I can fuck up and tests may fail. I fix the failing code to still pass the test. I know I delivered code that met the requirements, hopefully improved it, but I know I didn’t fuck it up enough to not do what it’s expected to do.
Plus source control…I mess around with code, my tests all pass…I commit it…I mess around more, can’t get the tests to pass, oh well quitting time roll back to previous working commit. Boss may be mad I didn’t improve it but at least I didn’t break it. Zero gain day is better than negative gain…
It might be a side effect of my work environment. I make the equipment that tests electronic medical implants. Theoretically if a unit put 1A of charge out instead of 1ma that could kill a person. Now on a practical level that’s not possible with our devices and even if it was we should be able to identify and prevent that unit from reaching the field.
Yes you are right, you want 99.99% uptime you need this stuff. In the field I’m in a single case escaping test can be months of engineering time to investigate, root cause analysis to determine the actual cause, expensive fixes for the short term and even more expensive fixes in long term to upgrade everything so it never happens again.
Boss being unhappy that you missed something is minor. Their boss’s boss’s boss is the real issue. That said we get regularly audited both in-house and external agencies so it’s unlikely. Multiple lines of defense, have a computer check it, have a person check that the computer actually checked it, have a computer verify that the person actually verified it. Have each of those systems regularly audited and verified to be effective.
It’s expensive but it is what is needed to be in this field.
Ok,this maybe too nerdy of a topic for here but that’s why I love unit tests.
Basically I write a piece of code that gets this input and generated that output. I also make a test to verify that I get a certain output given a certain input.
Now if I spend all day futzing within that code , changing variable names, refactor and extract a large function to 10 small ones, decide to re-write all the SQL queries to linq arguments…I can fuck up and tests may fail. I fix the failing code to still pass the test. I know I delivered code that met the requirements, hopefully improved it, but I know I didn’t fuck it up enough to not do what it’s expected to do.
Plus source control…I mess around with code, my tests all pass…I commit it…I mess around more, can’t get the tests to pass, oh well quitting time roll back to previous working commit. Boss may be mad I didn’t improve it but at least I didn’t break it. Zero gain day is better than negative gain…
All true! And if you want the service to be up 99.99% of the time, you can’t rely on waking someone up to fix it.
It might be a side effect of my work environment. I make the equipment that tests electronic medical implants. Theoretically if a unit put 1A of charge out instead of 1ma that could kill a person. Now on a practical level that’s not possible with our devices and even if it was we should be able to identify and prevent that unit from reaching the field.
Yes you are right, you want 99.99% uptime you need this stuff. In the field I’m in a single case escaping test can be months of engineering time to investigate, root cause analysis to determine the actual cause, expensive fixes for the short term and even more expensive fixes in long term to upgrade everything so it never happens again.
Boss being unhappy that you missed something is minor. Their boss’s boss’s boss is the real issue. That said we get regularly audited both in-house and external agencies so it’s unlikely. Multiple lines of defense, have a computer check it, have a person check that the computer actually checked it, have a computer verify that the person actually verified it. Have each of those systems regularly audited and verified to be effective.
It’s expensive but it is what is needed to be in this field.