Developers: Be proud to fail

Developers: Be proud to fail

The concept of failing is generally not something you should be proud of, but in fact in IT development this is something you should consider as positive. Let me explain why.

First let’s define what it means to fail. Failing in our case as nothing to do with creating bugs, failing is about detecting potential mistakes in advance and blocking the delivery process.

For example, you fail when you can not compile, you fail when your unit tests fail, you fail when your PR is not validated, you fail when your metrics are not compliant, you fail when your CI tells you it can not build, you fail when your CD can not deploy. All of this is a fail.

On the other hand, an incident in production, a lethal bug in your app, all those things are not failures, they are professional mistakes, they are everything that will destroy the trust people could have in your work. They are everything that will make your users use your app or quit it because its buggy and instable.

So please fail everyday and fail fast.

The faster you fail, the faster you fix and the lower is your risk to deliver bad things.

You should have multiple checkpoints where it is allowed to fail. For example, my “cycle of failure” is (ordered one):

  • fail to compile
  • fail in commit naming (naming convention in commit)
  • fail in architecture
  • CI fails to install dependencies
  • CI fails to build after a clean
  • CI fails to build in develop
  • CI fails on unit tests
  • CI fails on metrics (CCN, Code Coverage, Static analysis, code duplication)
  • fail on PR
  • fail to merge
  • CD fails to install dependencies
  • CD fails to build after a clean
  • CD fails to build in release with warnings (no warning allowed in release)
  • CD fails to code sign
  • CD fails to deploy

So now you can tell your manager: Yesterday was a good day, I had loads of failures!

And when she/he will look unhappy just add: “Those failures were detected fast and everything is fixed so our risk has decreased!”