The 3 Instil Check-in Commandments

Before committing any code to your master, or feature branch, you should always consider the three check-in commandments.

1) Could Chuck Norris understand it?

We all know that Chuck Norris has mastered a lot of skills, but software development is not one of them. Let’s assume, and rightly so, that Chuck is selected to go in the first wave of Mars colonists. Once the colonists reach Mars they have a space craft which allows them to fly around the planet to start their world making machines. One day Chuck is out in the craft with his buddy. His bud, let’s call him Jean Claude, is returning to the craft from a spacewalk and the airlock hatch won’t open. Chuck contacts HQ and they tell him that Jean is going to die if he can’t patch the software there and then.

You wrote the software.

If Chuck opens the code to find long winded methods with lots of magic sauce and time warping indirection it is likely his buddy will die and no one will be able to hear him scream, but if it is beautifully decomposed and reads like good prose he going to fix that door and his sparring partner will live to shoot another scene.

If your code does not live up to Chuck’s expectations you should always refactor it before committing.

2) Is it solid gold?

When you come to check in any code you should think to yourself. Is this solid gold? Deep down, in your heart, you will know if your update can be described as such. This is a visceral measure and can only be considered successful if your gut says so.

Although this is a very subjective yardstick there are some empirical measures you can use to help you make the decision:

• Does the code build cleanly?
• Do all automated tests pass?
• Have you met all the project coding standards?
• Do all static analysis tools run cleanly?
• Have you tested your change?

If you are not satisfied with the carat rating of your work you should mitigate for that. This is likely to either be additional work before the check-in, or perhaps adding a task to a backlog. Always be wary of the later approach as too much technical debt will always get you in the end.

3) Would I fly in this plane?

When I am flying in a plane I like to imagine that the software has full test coverage and does nothing unexpected. When writing your own software you should treat it no differently. Would you get on a plane running your check-in? If not take a step back and make it so. After all Chuck is colonising Mars for mankind and he is relying on you.