“It Can’t Happen”

In engineering or other fields, the mentality “it can’t happen” could do harms to the project. This becomes prevalent in the software engineering and IT profession as well.

If, for example, you have stumbling across the application codebase, run it, and found something that surprise you, reevaluate your assumptions, be willing to debug it#. Don’t just “know” your code works, prove it, in this context, with this data, with these boundary conditions. Add new test# to it, Crash Program Earlier# or put some Assertions#. You can go further by adopting Defensive Programming#, enforcing checks on precondition, postcondition and class invariant by Design by Contract (DBC)#.

Links to this page
  • The Pragmatic Programmer
  • Test Driven Development (TDD)

    Note: Even with extensive testing, one could not avoid drawing a #naive assumption about a routine, resulted in false causalities and coincidental outcomes. Hunt et al. advices “Don’t assume it, prove it”.

  • Box Evaluation

    Be aware of your environment. Recognising what’s the constraints that placed upon us and how much freedom do we possess. It is essential in ultimately solving the puzzle given to us. Challenge any preconceived notions and evaluate whether they are real constraints, no matter how ridiculous they might sound to you. If you think that “It Can’t Happen”#, then prove it. It is recommended to find out the most restrictive constraints first, then fit the remaining constraints within them.

  • Assertions

    In C and C++, the keywords assert and _assert are usually viewed as a Debugging Tools. However, as recommended by Hunt et al., if you ever feel that #something can’t happen, it is a great opportunity to ensure it won’t by using assertions. Even though assertions can add overhead to the program, turning them off when building the binary is a bad idea since it assumes tests alone would find every bug in the codebase which is not the case.

#psychology #lifestyle