With software this should be your test suite. No test is too simple. No feature or detail too small to test. Replace the line "relentless checklist" with "relentless testing" and you're good to go. Don't deploy before all tests are green and that's the same as not flying without running through your checklist.
I grew up flying with my dad in his Cesna 172 and admiring how well the pre-flight checklist worked. When I first heard about TDD, I immediately recognized it as the same process, except automated.
That's what I first thought. Then I realized that test suites as most people think of them would not have caught the Heartbleed bug, whereas a checklist like this would have done so.
Testing is testing, but there are different ways of thinking about it, and different ways to have it embodied. Test suites are one embodiment, and higher-level checklists can complement them.
I guess I've always thought of my integration tests as the higher-level checklist. I've only done web development, so that works. I could see how if you're writing software for something as important as OpenSSL then you might need an extra set of checks, but there's still room for human error. Seems like there should be someway to automate everything required to deploy software.
But I realize this is an idealistic approach. The reality is that a good test suite with higher-level checklists is probably more practical.
Comments
With software this should be your test suite. No test is too simple. No feature or detail too small to test. Replace the line "relentless checklist" with "relentless testing" and you're good to go. Don't deploy before all tests are green and that's the same as not flying without running through your checklist.
I grew up flying with my dad in his Cesna 172 and admiring how well the pre-flight checklist worked. When I first heard about TDD, I immediately recognized it as the same process, except automated.
That's what I first thought. Then I realized that test suites as most people think of them would not have caught the Heartbleed bug, whereas a checklist like this would have done so.
Testing is testing, but there are different ways of thinking about it, and different ways to have it embodied. Test suites are one embodiment, and higher-level checklists can complement them.
I guess I've always thought of my integration tests as the higher-level checklist. I've only done web development, so that works. I could see how if you're writing software for something as important as OpenSSL then you might need an extra set of checks, but there's still room for human error. Seems like there should be someway to automate everything required to deploy software.
But I realize this is an idealistic approach. The reality is that a good test suite with higher-level checklists is probably more practical.
If your checklist says "memcpy is forbidden", and you encode that in a static analyer (test), heardbleed would be prevented.