Relieve your Codebase from Paranoia and Gain Confidence with Offensive Programming

Of course, errors are not good for a chess game, but errors are unavoidable and in any case, a game without errors, or as they say ‘flawless game’ is colorless. – Mikhail Tal

Imagine yourself as a chess player instead of a Software Developer.

How would the development of your pieces adjust to the competitor’s challenges? Are you going to become extremely defensive, or will you allow yourself calculated risks and planned sacrifices by having the end game all the time in your mind.

I would like to talk about my own evolution on the intention behind opening variations and how I managed to gain confidence in my codebase through some techniques.

First I started incorporating the Defensive programming technique, this style is dating from the early days of C and its aspiration is to:

• Ensure code correctness and reduce the number of bugs
• Make the software behave in a predictable manner despite unexpected user interactions.

However, my issue with defensive programming is that in practice is taken past what is described to a very sad and ugly place. I found that important things about my codebase suffer because of this:

• Unnecessary code
• Readability
• Maintenance
• Hiding exceptions

When looking at defensive code, it’s hard to grasp the intention: was it added for safety or is there a valid reason x can be null? Is it expected behavior, or is it an unhandled error?

Software development should not feel like playing the whack-a-mole game

My opinion is that this technique is designed to deal with User input or External interfaces, and it should not progress beyond that scope.

Not being careful and not having the discipline of using the technique can be the cause of Paranoid Programming. This approach can be contagious, spreading like a wildfire in the codebase. And I don’t want to have any part of that again.

So how do we keep our sanity and can we take control of the board and strip our code of paranoia? I found that the answer to these questions was:

Offensive programming, just crash

• Stop hiding exceptions.
• Provide good stack trace, you can thank yourself later.
• Use assertions.
• Choose crashes over Logical errors, a much worse version of crashing.
• Crashing the program is permitted, rather than attempt to continue a possibly flawed process.

Recognize and use tools from your preferred language to help you. It should be the main carrier when adopting this technique.

Quick shout-out to Kotlin, this language provides some gems that can be used to enforce offensiveness.  Their intentions behind Null safety at compile-time, Capturing assumptions with require, check and assert, Aggressive or smart TODOs and many other concepts let you crash your program in the most fantastic ways.

• Start with handling the empty catch or else blocks, we all know you have one hidden somewhere deep in the codebase, go look at it. Handle them at your own pace.
• Use breadcrumbs, it will help when reproducing the issue, fail mindfully.
• Document the behavior, leave traces inside your code if needed.
• Reference your todos in your favorite project management tool, assign them and give them a deadline, much nicer approach than just looking away.
• Adopt incremental-roll outs.

Offensive programming goes hand in hand with the Agile methodology on a higher level. At our company, we like to follow these words.

Launch Fast – Break Mindfully – Fix Fast – Learn Fast

Recognized as one of our core strengths to deliver good code fast and to iterate fast on our changes. The more frequent deploys, the more information is being gathered, don’t be afraid to crash and detect failures at an early stage.

• Gaining confidence in your codebase takes a structured approach, be smart and understand that it is an ongoing process.
• Utilize the agile workflow, gambit and applying the Offensive techniques, it will gradually have much better results and create a healthier codebase.

Are you tired of being paranoid and overprotective about your codebase? Do you want to be in a company where crashes are encouraged and met with understanding? Check out our current job openings.