Programming by Coincidence

Key Insight

Programming by coincidence involves relying on luck and accidental successes, leading to false conclusions and potential disasters, much like a soldier mistakenly believing a minefield is safe after initial probes yield no explosions. This dangerous approach is characterized by writing code, seeing it 'seem to work' under limited conditions, and then progressing without truly understanding *why* it works. This ultimately results in code failures that are difficult to diagnose and fix because the foundational understanding was never established.

Coincidences manifest in several ways. 'Accidents of implementation' occur when code relies on undocumented or unintended behavior of routines, which might break if the underlying library changes or is 'fixed.' An example is calling multiple GUI rendering functions in an arbitrary sequence, where the success is coincidental, leading to slower, bug-prone code if not corrected. 'Close enough isn't' describes relying on approximate fixes (e.g., adding or subtracting '1' for time zone issues) instead of addressing fundamental flaws, which can lead to an unmaintainable codebase that is entirely incorrect and ultimately scrapped.

'Phantom patterns' highlight the human tendency to see patterns where none exist, like gambler's fallacies or assuming environmental differences for intermittent errors, instead of proving causality. 'Accidents of context' involve implicit assumptions about the runtime environment (e.g., GUI presence, writable directories, server time accuracy, network availability) that are not guaranteed, potentially leading to 'cargo cult' code that imitates form without understanding content. To program deliberately, always be aware of actions, explain code to others, avoid coding with incomplete understanding, plan, rely only on reliable things, document assumptions, test assumptions with assertions, prioritize effort on hard parts, and be ready to refactor rather than being enslaved by existing code.