A Proposal for an Antifragile Software Manifesto
sciencedirect.com
A Proposal for an Antifragile Software Manifesto
1–10 of 46 posts
Re: A Proposal for an Antifragile Software Manifesto
#2"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.
Re: A Proposal for an Antifragile Software Manifesto
#3I think a manifesto with a lot of buzzwords ends up being quite fragile.
Re: A Proposal for an Antifragile Software Manifesto
#4This will be difficult to do in text (imagine a triangle):
Quality
Time Cost
Re: A Proposal for an Antifragile Software Manifesto
#5"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.
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.
Re: A Proposal for an Antifragile Software Manifesto
#6This 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?
It can't be quality because "[e]rrors are the primary source
of an antifragile system", quoting from the paper directly.
Re: A Proposal for an Antifragile Software Manifesto
#7I think a manifesto with a lot of buzzwords ends up being quite fragile.
I suspect you might not be applying the right ontology to fully elaborate the reification of the concept.
Re: A Proposal for an Antifragile Software Manifesto
#8This 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?
Honestly, I would love it if anyone could make the decision at all. Usually it's "I want all three".
Re: A Proposal for an Antifragile Software Manifesto
#9This 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?
Honestly, I would love it if anyone could make the decision at all. Usually it's "I want all three".
Yep, managers seem to think the triangle can be overcome with enough money/prowess/brute force.
Re: A Proposal for an Antifragile Software Manifesto
#10"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.
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 glob…
> 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.)