A swan in Europe was a white swan. So, naturally, swans were thought of as only white by Europeans until news came from travelers to Australia in the late 1600s where black swans are in fact relatively common. Black swan events can turn a worldview upside down. They are unprecedented, unexpected, rare, and with a significant impact.

The infrequency of black swan events means prior data about them is too little to reliably guess the likelihood of one, and you may not even think to anticipate the event anyway. Except after the fact, when all of a sudden many people will claim to have predicted it — black swan events are prone to be rationalised in hindsight, believing that all the signs were there beforehand even if they weren't.

The idea of black swan events is from Nassim Nicholas Taleb. He writes:

"One single observation can invalidate a general statement derived from millennia of confirmatory sightings of millions of white swans. All you need is one single black bird."

Examples Taleb gives include the September 11 terrorist attack, the 2008 financial crisis, World War I, or the rise of the Internet.

More Taleb sketches: on mistakes, the firehouse effect, and the Lucretius problem. Also, hindsight bias.

Black swan events

Just as mistakes and the unexpected are part of life, bugs are part of software development. In general, the longer the time between when a bug was first introduced and when the bug is identified and fixed the more expensive it is in both time and money.

If you spot a bug as you're writing a new feature everything is fresh in your mind and it can sometimes take just a moment to fix.

If a bug turns up later or perhaps soon after it's deployed you might have an idea of where it might be and track it down fairly quickly.

If a lot of time has passed since a feature was worked on and a bug is spotted or tackled then it might take a fair bit of time to figure out how everything works again before you can fix it.

And if a really long time has passed then, aside from the cost of interrupting what you are otherwise working on, it may not even be clear what was intended by the original code, probably written by others, and there's a fair chance more has been built on top of the buggy code making it more complex and a bigger task to tackle. The only way to solve it may be stepping through and figuring out behaviour slowly and steadily line-by-line.

You could probably replace 'bugs' with 'code' 'problems' or 'mistakes' in most scenarios.

Aside from it matching my experience, Joel Spolsky gives a nice explanation in his classic article The Joel Test.

The cost of fixing bugs

Only dead fish go with the flow. A nice reminder to swim your own path in life and be true to yourself.