Offensive programming is a software development philosophy that deals with software bugs by having the program fail fast and visibly, rather than attempting to hide or recover from them.^[1][2] The goal is to make bugs obvious during development and testing, under the assumption that unexpected internal errors should be fixed by the programmer, not tolerated by the running software.

This approach is considered a branch of defensive programming because it is a strategy for handling errors. However, it contrasts with defensive techniques that might mask a bug by using default values or continuing to run in a degraded state. Instead, offensive programming often uses tools like assertions to halt the program immediately when an invalid state is detected, making the source of the problem easier to identify and fix.

The premise for offensive programming is to distinguish between expectable errors, coming from outside the program's line of defense, however improbable, versus preventable internal errors that shall not happen if all its software components behave as expected.

Contrasting examples:

Offensive programming is concerned with failing, so to disprove the programmer's assumptions. Producing an error message may be a secondary goal.

• No unnecessary checks: Trusting that other software components behave as specified, so to not paper over any unknown problem, is the basic principle. In particular, some errors may already be guaranteed to crash the program (depending on programming language or running environment), for example dereferencing a null pointer. As such, null pointer checks are unnecessary for the purpose of stopping the program (but can be used to print error messages).
• Assertions – checks that can be disabled – are the preferred way to check things that should be unnecessary to check, such as design contracts between software components.
• Remove fallback code (limp mode) and fallback data (default values): These can hide defects in the main implementation, or, from the user point of view, hide the fact that the software is working suboptimally. Special attention to unimplemented parts may be needed as part of factory acceptance testing, as yet unimplemented code is at no stage of test driven development discoverable by failing unit tests.
• Remove shortcut code (see the strategy pattern): A simplified code path may hide bugs in a more generic code path if the generic code almost never gets to run. Since the two are supposed to produce the same result, the simplified one can be eliminated.

• Fail-fast system