
A Proposal for an Antifragile Software Manifesto - jhrobert
http://www.sciencedirect.com/science/article/pii/S1877050916302290
======
danielvf
"We value reliable software", is nice, but everyone values that.

But if you said "We value reliable software over meeting deadlines", then
you'd actually have said something.

The power of the Agile Manifesto was that it clearly identified tradeoffs they
were willing to make.

~~~
kazinator
They try to prioritize their principles, but they are vague. Let's see:

> _Our highest priority is to satisfy the customer by building a non-linear,
> proactive, and self adaptive system_

Okay, firstly, what is that? And secondly, does it serve the customer if those
are not the customer's requirements?

What if I don't want a "self adaptive" system, whatever that is? It could be
bad: self-adaptive software keeps some global state somewhere and doesn't
quite ever do the same thing twice. If I require something that produces
exactly the same output every time I feed it a given input, then I'm ill-
served as a customer if I'm handed some self-adaptive contraption.

~~~
edocecrous
_> what is that?_

A collection of popular buzz-words in contemporary software engineering
research.

 _> And secondly, does it serve the customer if those are not the customer's
requirements?_

These are never _any_ customer's requirements. Not a sane customer, at least.
Instead, they are (conjectured, probably correctly, to be) generalizations of
sufficiently many customers' requirements.

But you're correct -- most customers don't want or need any of those things
(except non-linearity. But every piece of software everywhere has this
spades.)

~~~
matt4077
Or you could read the book. I haven't (summer reading list, again). But it's
got a 20-page bibliography, and appendices with all sorts of greek letters
that define, well, a lot. I think.

The Black Swan was also by Taleb and probably the most influential finance
book of the last 20 years, plus a great read for anybody thinking in
'systems'. It'd give the idea the benefit of the doubt. Sometimes words have
no meaning, sometimes it takes some work.

~~~
edocecrous
The parent didn't ask what _antifragile_ means. The parent asked what _non-
linear, proactive, and self adaptive_ means, especially when taken as
requirements for a software system.

Reading Taleb's book to answer _that_ question is probably a lot like trying
to extract evolved dogma out of a religious text because each of those words
has taken on a life and meaning of their own in SE literature. You can
probably eventually get close, but you're better off just reading a few SE
papers on those topics and inferring the authors' intended meaning.

------
SkyMarshal
Antifragile refers to a property in which a system does not just resist
breaking down under disorder and stressors (robust), but gains/learns/becomes
stronger. A good example is how bones heal back stronger where they were
broken.

While we are currently able to build self-healing systems of a sort, fault-
tolerant Erlang systems being a good example, it doesn't seem we can build
systems that are truly antifragile on their own, that would require strong AI.
Otherwise, humans monitoring and intervention are required to improve systems
under duress.

This manifesto does include "team" and "organization" to account for that, but
a true autonomous antifragile system is a ways off.

~~~
ctvo
Your bone example isn't accurate
([http://www.nytimes.com/2010/10/19/health/19really.html](http://www.nytimes.com/2010/10/19/health/19really.html)).
The example used in the book are muscles (stress -> breakdown -> creating
stronger muscles)

~~~
sitkack
Maybe more accurately, bones subject to survivable progressively more intense
stresses are stronger. It would be like an autoscaling algorithm under
increasing loads (not delta function loads).

------
devishard
TL;DR:

1\. Our highest priority is to satisfy the customer by building a non-linear,
proactive, and self adaptive system.

2\. We welcome changing scenarios where unexpected events (Black Swans) are
the real paradigm shifting entities.

3\. We deliver assuring embedded and adaptive fault tolerance.

4\. All stakeholders, and the broader environment, lead the antifragile
organization.

5\. Build antifragile projects around motivated, skilled and open minded
people. Give them the environment and support they need, and trust them to get
the job done.

6\. The most efficient and effective method of building an antifragile
organization is building on honest, open and transparent communication.

7\. Continuous exposure to faults and automatic fixing is the primary measure.

8\. An antifragile organization promotes a context aware environment. The
stakeholders should be able to maintain a system indefinitely.

9\. Continuous attention to technical excellence, reality, redundancy.

10\. Error loving - the art of learning to be antifragile – is essential.

11\. Antifragile architectures emerge from self – organizing, context aware
teams.

12\. At regular intervals, the developing team reflects about the context
situation, on how to become more effective, then tunes and adjusts its
behavior accordingly.

------
mk89
Why do people still keep writing Manifestos in 2016? I thought it was evident
they don't work out - or that they get "abused" as political opinions.

We don't need Manifestos, we need people who think about each situation and
problem differently, basing their thoughts on experience, knowledge, and
communication. You can write all the s* you want, but you won't get that
thanks to 10 lines - which will be always ambiguous and misinterpreted, then
what? Will you write another manifesto?

We need experience, we need to learn, we need to improve. You literally need
to fail to get any improvement. And companies need to keep their people, they
need to invest in people, instead of relying on a bunch of buzzwords or
manifestos to prove themselves "cool" and up-to-date. Stop doing that. Make a
step back, give your people time to think, talk to them, and give them the
right resources.

~~~
ArkyBeagle
We may need those things, but it's increasingly clear that we cannot afford
them so far as we know. I'm using "afford" widely - if we needed those things
and understood that need properly, we'd have them. It's the mythic "$20 bill
on the ground" \- if it was really there, someone would have picked it up by
now.

it's no great secret how to write robust and unfragile software. We apparently
only lack the will to do it.

I've been in spots where we _priced_ a defect, and they _still_ didn't want it
fixed.

~~~
mk89
I have also worked for such companies. It's more common than what you and I
think :)

However, they cannot afford them because they simply don't want to be the
best. Look at those companies who invest in people and give them time to
grow/think/be. Their products are above average. Why?

When you want to be the best, you simply have no other way than "thinking" and
"reasoning". Unless you are just lucky and you get one or two Einstein[s]. But
even then, if you don't give such a genius the right environment, he is gonna
do his best to get away from you.

What you call will I call it attitude towards business. Nowadays we don't
write software anymore to make a product last at least 10 years, we build
companies to be sold in order to get someone (the founder) rich so that he can
invest in new crap to sell. Why should he waste 500-1000 $ when that money can
go to a new feature or an "important" bug (coming from a bigger customer)?

------
keithnz
I think a manifesto with a lot of buzzwords ends up being quite fragile.

~~~
kazinator
I suspect you might not be applying the right ontology to fully elaborate the
reification of the concept.

------
jmspring
As with any manifesto, words, interpretation, and practice are where they
fail. I've been through the Agile/Scrum classes, yeah, great. Does management
buy in, despite professing such? Yeah, not so great.

Unfortunately, for me, whenever I see the word "manifesto" in relation to
computers, this is the one I immediately remember...

[http://phrack.org/issues/7/3.html](http://phrack.org/issues/7/3.html)

~~~
Udik
And this is the one I remember instead:

[http://programming-motherfucker.com](http://programming-motherfucker.com)

~~~
soft_dev_person
After reading that, the world is now cyan. Thanks.

------
jimjimjim
This will be difficult to do in text (imagine a triangle):

    
    
                    Quality
    
            Time                Cost
    

Right, which one is more important? and more importantly who gets to decide
which one is more important?

~~~
Joeri
You can have all three. Prioritizing quality from the start, by doing design
reviews, pair programming, tdd and so on, will actually reduce time needed to
deliver fully functional software, and therefore lower overall cost.

~~~
icebraining
_reduce time needed to deliver fully functional software_

Except you can deliver a cheaper product faster if it's not fully functional,
hence the triangle.

------
jcbrand
Interesting that the concept of Antifragility is gaining traction with regards
to software.

Back in 2014 I wrote a blog post "Antifragile Software Ecosystems" that
discusses how IMO antifragility relates to how software is developed.

[https://opkode.com/blog/2014/01/14/antifragile-software-
ecos...](https://opkode.com/blog/2014/01/14/antifragile-software-ecosystems/)

------
norswap
I was kind of hoping for a document that outlined principles to make the
engineering process truly antifragile, i.e. one that would thrive under
contingencies.

Honestly, I have trouble fathoming how such a thing would be even possible in
the realm of software. Maybe a system that "learns" previous failures and
proactively monitor failure conditions / throttles contended ressources?
(Seems quite specific already)

And the document surely didn't tell me.

~~~
colbyh
I actually think the former would be more within in the spirit of Taleb's
book. software is the result of a complex, sometimes problematic process and
not every piece of software needs to be antifragile. when bugs or system
outages pop up it isn't the responsibility of the software to fix itself, it's
the responsibility of the team behind it.

------
kapitalx
Chaos engineering falls in this category:
[http://principlesofchaos.org/](http://principlesofchaos.org/)

------
bernardlunn
I think this is more about tools than process. Specifically tools to assess
fragility (bad dependency patterns). You cam only manage what you can measure.

------
nikolay
When in 2009 I was calling it "Fragile," not "Agile," people were laughing at
me as yet again I wasn't politically correct!

~~~
Gonzih
I don't think it's mainly about agile. There is plenty of good examples of
fragile OSS out there that has nothing to do with agile. Entire npm ecosystem
is very good example.

~~~
nikolay
It's not only about Agile, but incremental development is always detrimental
especially for complex projects. Also, most companies apply some ghetto
version of Scrum, most don't even know what SOS (Scum of Scrums) is, pick and
treat the Scrum Master incorrectly, don't even do Planning Poker, don't use
Epics at all, don't define stories right, don't use burndown charts at all,
etc. In most cases, I see Scrum as an eyewash for the business. It's a pseudo-
scientific approach to prove to business we've done something this week, and a
solid excuse for missing deadlines, etc.

~~~
matthewmacleod
_It 's not only about Agile, but incremental development is always detrimental
especially for complex projects_

I really have to dispute that.

First, it's not really clear what you mean by "detrimental" \- is that to
software quality, or development schedule, or suitability? Or all of them, or
others? Agile is very clear about the trade-offs - working products being more
important than documentation for example, or responding to change over
following plans.

Second, I don't think it's true. I've directly observed, in multiple
organisations, that agile development is perfectly capable of delivering good
systems on-budget and on-schedule. If anything, it's _especially_ good for
complex systems, which are those most likely to require flexibility and have
hidden requirements.

I also dispute the idea that "ghetto Scrum" is invalid. Development processes
should be tailored to the requirements of the product, organisation and team.
Not every team needs epics or planning poker or scrum of scrums, and it's
totally valid to take some of the ideas of scrum and apply them to your own
development process without having to buy the whole thing.

I consistently see agile development hand waved away with this argument that
it doesn't work because there are companies which do it badly, and it's
baffling to me.

~~~
nikolay
You can't build a house from the roof, but that's what Agile indirectly makes
you do. Although Waterfall is the other dangerous extreme, it makes you think,
correctly estimate, and plan. You can't apply Scrum to every project -
especially those with firm deadlines! Yeah, it's good for startups, where
feedback and market shape your product, by can you build a spaceship using
Scrum? Honestly, as an engineer, even when I use Scrum, I still use Gantt
charts, and that's another thing that makes people make funny faces in Scrum.

~~~
matthewmacleod
_You can 't build a house from the roof, but that's what Agile indirectly
makes you do._

And you can't compare software with a house, or even a spaceship :) For one
thing, we have far fewer constraints.

When we build software we are (generally, though not in every case) building a
_solution to a problem_ rather than a strictly defined product - and in many
cases, we are unsure about what the final product will look like! Spotify did
a good illustration of this process in this slide:
[http://www.chrisyin.com/images/spotify-
mvp.png](http://www.chrisyin.com/images/spotify-mvp.png) \- the point is to
continuously deliver features to customers and using the feedback generated to
inform ongoing development, which like you point out, is absolutely essential
in some cases.

 _, but that 's what Agile indirectly makes you do. Although Waterfall is the
other dangerous extreme, it makes you think, correctly estimate, and plan._

That's perhaps the idealistic view, but there is a cost there too - change
becomes much harder. I also suspect that there is no such thing as a correct
estimate!

 _You can 't apply Scrum to every project - especially those with firm
deadlines!_

Maybe not, and Scrum is not the ideal methodology in all cases - but it's also
not the only way to be agile. It's also a fallacy that planning in advance
means a project will meet a deadline - let's remember that Scrum doesn't
typically mean you are doing different work, just that you are slicing it and
delivering it differently. I'd argue that one of the main differences is that
if a Scrum-developed project misses it's deadline, you _still have a working
product_ \- it just doesn't necessarily have all the features you'd like. But
if you are correctly building the most important and complex features first,
then that's potentially much better than the "waterfall" outcome of "the
product isn't complete and can't be used".

 _can you build a spaceship using Scrum?_

I probably wouldn't want to try it, but this is an example of a project with
incredibly tight constraints on what can be built - far more than software
typically is. But I'd imagine it's also possible to build components of any
product in an agile manner.

 _I still use Gantt charts, and that 's another thing that makes people make
funny faces in Scrum._

That's great, and it's something that should be encouraged - development
methodologies should be determined by what works well for you as a developer,
team, or company! A Gannt chart, assuming you are changing it as product
requirements change, is basically the same as a Scrum burndown chart with
additional planning thrown in. And we do the same sort of thing - "these are
the epics, this is how long we estimate they will each take, and here is the
order we will do them in." It's not so different.

Ultimately these methodologies are designed to help projects cope with change,
which has been a long-term problem in correctly sizing and executing software
projects. Maybe they won't always work for every project with particular
constraints, but I reckon they are far more applicable than some people
believe.

