
Principles of Antifragile Software - agumonkey
https://docs.google.com/viewer?url=arxiv.org/pdf/1404.3056
======
Spearchucker
Anti-fragile has some great objectives. However they're still firmly in the
realm of "science" and have yet to make the transition to "engineering". As
such my interest is academic.

Practically, I remain a fan of recovery-oriented computing [1] - reducing the
impact of harmful events, like Bohr- and Heisenbugs, amongst others.

In recovery-oriented computing a Bohrbug, being mostly deterministic and easy
to detect, would spawn an urgent alert. Conversely, a Heisenburg enters
probation in that execution (or the execution path) is re-attempted. If that
fails the app is re-started. If that fails the machine is re-started. If that
fails the machine is re-imaged. If that fails the machine is removed form the
farm. Automating this process is not easy ( _especially_ for desktop/native
apps, which is a big part of what I do), but the concepts are (to me) good to
strive for.

[1] [http://roc.cs.berkeley.edu/](http://roc.cs.berkeley.edu/)

------
DanielBMarkham
I've never hunted, nor hunted with dogs.

I am not a hunter. My experience of hunting consists of reading Tolstoy and a
rather unfortunate encounter I had with a squirrel when I was 10.

But as I understand it, there's a sound dogs make when they've picked up a
scent and are after game. It excites the rest of the hunting party. The chase
begins!

I get this feeling in the tech community when we're talking DevOps, XM, and
anti-fragile software. I can see it in this paper. We're nowhere near where
we're going to end up, but the principles are in place and the community is
justw sorting through them to get to the destination. There's some really cool
stuff out there, and the next decade or so is going to be a blast.

------
SkyMarshal
Quote from Greg Maxwell, Bitcoin core dev: _" I hate it when people call
Bitcoin anti-fragile. It's not anti-fragile, when it breaks I have to fix
it!"_

Software systems, in which the term "system" includes the humans constantly
monitoring, fixing, and improving them, may be anti-fragile, but we probably
won't have true anti-fragile software until we also achieve strong AI. Till
then it's just robust, or perhaps adaptively robust, at best.

~~~
lukifer
I think the anti-fragile concept applies not to the codebase, but the
processes and ecosystem surrounding it (users, devs, communication tools,
social dynamics). Software is best modeled as a living thing intertwined with
humans, not just the current snapshot of its source code.

For instance, a web app with a public bug tracker is more anti-fragile than
one without. I've also heard strategies of making errors and warnings public
on production, so that problems stick out like a sore thumb, and get fixed
more quickly. (Obviously, this isn't a good idea in all cases.)

------
reality_czech
Can we go back to using the word "robust"?

Neologisms and jargon are anti-good.

~~~
bahmutov
Anti-fragile and robust are two different concepts as defined by Nassim Taleb.
Anti-fragile software is exposed to low level stress, and evolves to survive
it. Robust software is a static snapshot.

[http://bahmutov.calepin.co/review-antifragile-by-nassim-
nich...](http://bahmutov.calepin.co/review-antifragile-by-nassim-nicholas-
taleb.html)

~~~
bluecalm
It's learning from errors and failures or evolving or self-correcting.

The only real function that neologism serve is to ensure that there are
several pages to fill with easy writing about examples of things that are
robust and things that are fragile. Really, when reading about concept of
learning from mistakes (or in case of software self-correcting) not many would
find examples of fragile things interesting. Just because you are defining
neologism which have perfectly good equivalents already doesn't make it any
more compelling. You just fill paragraphs with boring fluff and make reader
wonder why the hell you are not jumping to the point already. This is
unfortunately also visible in the paper from OP as, following Taleb, about
half of it is concerned with giving murky definition of completely redundant
term and then telling the reader what it is and what is it not with numerous
examples.

The author would do well to remove all the references to anti-fragile and
Taleb and substitute those with some history of self-correcting software.
Maybe try to research who first wrote about it or tried to construct working
code. You know, like some information and background about the concept instead
of redefining it and then doing a session of mental masturbation over it.

~~~
graeme
Self-correcting isn't quite the right term, though it's closer than robust.
Something antifragile won't necessarily self-correct if left alone.

Instead, antifragile refers to something that improves when subject to
disorder and shocks.

It's a new word for a concept we can understand, but have no word for. Lacking
a word for something severely impairs our ability to talk about it.

To validly criticize the word, one should first show that they understand
what's meant by it, and propose an existing term that captures that. None of
the critiques in this thread have done that.

------
hackaflocka
"You've reached the bandwidth limit for viewing or downloading files that
aren't in Google Docs format. Please try again later. You can also try to
download the original document by clicking here."

~~~
greenyoda
Downloading the original works just fine. Here's the URL:

[http://arxiv.org/pdf/1404.3056](http://arxiv.org/pdf/1404.3056) (PDF
document)

------
mad44
I had blogged about Antifragility from an engineering perspective last year.
Glad to see this is getting attention.

[http://muratbuffalo.blogspot.com.tr/2013/06/antifragility-
fr...](http://muratbuffalo.blogspot.com.tr/2013/06/antifragility-from-
engineering.html)

------
TheLoneWolfling
A closely related thing:

If you're designing a programming language implementation, explicitly
randomizing implementation-defined operations makes a whole lot of sense. It
trades dev time for debug time, and in general fixing bugs during initial
development is a whole lot easier than fixing them after-the-fact.

For example, a robust hashmap might randomize the order of iteration over
elements 1/2 the time, or a robust priority queue might randomize the relative
order of elements with the same priority. Or even randomly changing the order
of evaluating function arguments. Or a function with a callback that is
defined to potentially be called multiple times (distributed systems, etc)
might explicitly call the callback a random number of times.

It might make more sense to only do some of these on debug builds.

~~~
thesz
Please, find a language where such behavior is a matter of library.

[http://en.wikipedia.org/wiki/QuickCheck](http://en.wikipedia.org/wiki/QuickCheck)

~~~
TheLoneWolfling
Well, Go has (limited) randomization of hashmap iteration order.

------
api
There's work in the area of genetic algorithms and evolutionary computation
that might be applicable:

[http://www.kgi.edu/Documents/IEEE.pdf](http://www.kgi.edu/Documents/IEEE.pdf)

------
eruditely
Whenever I do my PHD, it will revolve around fourth quadrant ideas especially
in this domain. I just need to compile all the research that has been done and
get to work.

Glad to see this is getting the attention it should.

------
benihana
Etsy practices continuous deployment with whole swaths of code that weren't
built using TDD. Using automated monitoring of measurements[1] affords some of
the same confidence as automated tests. It's worth saying that having tests
and automated monitoring builds even more confidence.

[1] [http://codeascraft.com/2011/02/15/measure-anything-
measure-e...](http://codeascraft.com/2011/02/15/measure-anything-measure-
everything/)

