book review

Review of "Antifragile" by Nassim Nicholas Taleb

Subject your life to constant low levels of stress to prepare for unpredictable events.

"Antifragile" by Nassim Nicholas Taleb, ISBN 978-1400067824

Fragile = breaks quickly under stress: porcelain mug, glass statues, modern financial sector.

Antifragile = gets stronger under stress: nature, winning team during playoffs.

Mr. Taleb spends more than 500 pages and 24 chapters taking shots at things he thinks are overly complex, too large and ultimately fragile. I enjoyed extensive side trips into history and philosophy; it is a book that benefits greatly from instant word definitions provided by Kindle. While I was puzzled by some assertions (financial crisis in 2008 was due to Alan Greenspan meddling too much in the economy? metric system is less confusing than imperial units? all technology is due to tinkering, and nothing due to the applied science?), I liked the major theme of the book.

It is impossible to predict the catastrophic events (black swans), such as financial system meltdown, nuclear meltdown during an earthquake and huge tsunami. Our world is too complex to produce useful models, so there is no point (according to the author). Instead we should focus on fortifying things against "bad" things, and change their nature to become antifragile. By exposing humans or organization to low level stress, we make them stronger and more prepared to unforeseeable events.

Application to software

While reading the book I kept thinking how to apply this philosophy to software and development process.

  1. Make software units smaller. Large entities are by their sheer size are prone to collapse; often like a colossus they hide a terminal weakness.
  2. Since predicting exact flaws is futile, instead concentrate on avoiding technical debt. If the code is simple, well structured, tested, even if a bug is discovered, it might be simple to localize and fix.
  3. Expose software to low level stress to battle-harden it
    1. Open source it to allow outside review
    2. Design for reuse, since every application flashes out problems
    3. Try using more 3rd party libraries, to discover how your code works with code written by others.

Additionally, the team will become better with each obstacle by conducting root cause analysis, as well as periodic sprint retrospective meetings. Hopefully this would shift the people from merely surviving problems to learning from past mistakes and preparing them for any future event.