A Proposal for an Antifragile Software Manifesto
sciencedirect.com
sciencedirect.com
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.
> 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.
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.)
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.
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.
This reminds me of a Jamie Zawinski quote from the book "Coders at Work":
> [...] Are you trying to write good software or are you
> trying to be done by next week? You can't do both. One
> of the jokes we made at Netscape a lot was, "We're
> absolutely 100 percent committed to quality. We're going
> to ship the highest-quality product we can on March 31st."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.
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.
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.
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.
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)?
Unfortunately, for me, whenever I see the word "manifesto" in relation to computers, this is the one I immediately remember...
Quality
Time Cost
Pick any two...
In practice? Pick a spot inside the triangle.
Except you can deliver a cheaper product faster if it's not fully functional, hence the triangle.
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...
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.
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.
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 - 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.