The Complex Manifesto for Software Development

The world is more complex than people like it to be.

I regularly see blog posts of software experts providing us with values, principles, guidelines and practices to live our lives by. And all of them are good, and all of them are incomplete. I've seen improvements on the agile manifesto (Glen Alleman), additions to the agile manifesto (Jason Yip), conflicts over principles (Bob Martin vs. Joel Spolsky), controversy over practices (Ron Jeffries vs. me), and lots of other heated debates. Each discussion is valuable, and each is only half the story.

We're all seeking simple truths where there aren't any.

I believe it is time for a new manifesto. A manifesto of complexity. With this manifesto we must recognize that it is human to prefer simple solutions, but also that the world is more complex than we think. Well, here it is…

The Complex Manifesto

Each Problem Has Multiple Solutions
There's not just one way to solve the Rubik's cube. There's not one best way to run a business. There's not one best strategy to win at Risk. And there is not one best way to run a software project. Yes, we're human, and we like to be the ones who are right (even me). But we admit that others can be right as well.

Solutions Depend on the Problem's Situation
The form of each species depends on its environment. The best strategies in football depend on the opponents. The best marketing depends on the customers. And the best software development practices depend on the project. In software development there are lots of princes and nobles, but context is king.

Changing Context Requires Changing Solutions
When environments change, so do species. And good strategies for social networking now are different from what they were before. (Follow me on Twitter now, and we'll see how things have changed next year.) Therefore, when software project environments change, their processes much change accordingly.

Some Solutions are More Prevalent Than Others

Even before humans, ants and antarctic krill are the most successful species in the world. And tit-for-tat is one of the most prevalent survival strategies. But the silly looking blobfish has its place in the world too. And no game strategy is always superior. Likewise, some software development practices are wildly successful, but they will never replace all others.

For Every Solution There is a Best Situation
There's a good time and place for the Northern hairy-nosed wombat to exist. Granted, it's place in the grand tree of life is not big. But it is there. And I probably won a few games of Risk with some very strange strategies myself. Likewise, even the most uncommon software practices have their proper time and place in the world.

Solutions Change Themselves by Changing Their Situations
Movies that are released change the playing field of the movie business itself, and the new movies that are made. The memes in our mind change the way we think, and the new memes that we are willing to adopt. Similarly, our software practices change our projects' environments and the way we change the practices themselves. Any practice that is static, is likely to fail in the end.

Understanding Complexity Helps
in Applying Simplicity
Biologists, businesses and governments have often done much harm by not understanding the complexity of the world. Those who don't understand the way things work, have a hard time anticipating which simple solutions might work in solving complex problems. Even worse, simple regulations can have devastating effects when complexity is underestimated.

It Is Impossible to Predict the Best Solution
Though anticipation is valuable, it is impossible to know for sure which solutions will work, and which won't. Only with empirical findings in a real context can any claims be made of the success of a solution. We admit what we don't know, and that we have to try software practices in order to know if they work in our context.


The pure and simple truth is rarely pure and never simple. – Oscar Wilde

Everything should be made as simple as possible, but not simpler. – Albert Einstein

For every problem there is a solution which is clear, simple, and wrong. – Henry Louis Mencken

It is simplicity that makes the uneducated more effective than the educated when addressing popular audiences. – Aristotle

The Complex Manifesto does not invalidate any existing values, principles, guidelines, or practices. On the contrary, it says that all are valuable, when seen in their proper context. In software development, discussions should not be about who is right and who is wrong. Instead, people should concern themselves with who is right in which situations. We should not be interested in user stories vs. use cases, agile vs. cmmi, xp vs. scrum, or lean vs. agile. We should be interested in when to use what.

It is my hope that all software developers and managers learn to understand that there's no need to flame each other over methods, frameworks, principles, and practices. In a complex world there's a time and place (whether small or big) for every idea. The real challenge is in finding out which idea belongs where.

Thanks for reading! If you agree with this, then feel free to sign this article with your name. It's only a real manifesto when there are some signatures underneath it! ๐Ÿ™‚ Oh, and forward the link to your friends too!

(pictures by kevinzim, eye of einstein, Australian Museum Online and photobucket)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
The Decline and Fall of Agilists
From Complexity Theory to Practical Management
A Theory of Everything for Software Development

  • 5 Easy Questions for Paul Duvall
  • Video Killed the Agile Star...
Related Posts
free book
โ€œHow to Change the Worldโ€
  • Pawel Brodzinski

    While I agree with the list I don’t think we need a new manifesto. For experienced people in project management and software development this is fairly common knowledge and we follow this list.
    For people who believes there’s a silver bullet out there it won’t work anyway since it tells you pretty opposite thing.

  • Sander

    Sander Lems

  • Ram Manohar Tiwari

    Can we have a simpler version of ‘The Complex Manifesto’ please ๐Ÿ˜‰
    Ram Manohar Tiwari

  • Daryl

    Daryl Kulak
    I especially like this line:
    Any practice that is static is likely to fail in the end.
    Good job, Jurgen.

  • Mendelt Siebenga

    Mendelt Siebenga,
    I would like to note that in a sense this manifesto does invalidate some values, principles, guidelines, or practices. Not because they’re not useful in some situations but because they claim to be useful in any situation when clearly they’re not. While other values, principles, guidelines, or practices actually are “meta-practices” telling you how to adapt instead of how to do things.

  • terry

    I find myself referring to your complexity theory blog quite many times when explaining software design principles.
    Good work.
    Terry YinZhe from Hangzhou, China.

  • David Kotch

    Nice post Jurgen!
    Instead of working out solutions, I’ve seen quite a few teams bog themselves down in debates over processes, arguments over backlog and bug tracking tools, holy wars about languages, and debates over core hours (which gets really ridiculous when it comes from multinational teams).
    But teams quite often can’t see what’s right for a particular context because they’re already biased toward a process they already know, a habit they’ve already set, or a language or framework they’ve already mastered. Sometimes the best solution is to have strong leadership come in and squash the bickering with a decision. Any decision on process is often better than indecision or a protracted attempt to find the perfect process.
    But beware a consultant who uses the inherent complexity of technology to put fear into their customers — to drive up costs, or to buy more time. I’ve often seen bureaucrats stir up a debate for the sole purpose of buying more time for their men on the trenches to come up with a proof-of-concept or viable solution. But in the end, as long as there are no ulterior motives, it’s better to hear passionate debate than the crickets of indifference.

  • Cory Foy

    Hi Jurgen,
    Part of me wonders if in fact your manifesto is targeted at a different audience then things like the Agile manifesto. Reason being that I can see teams pointing to things like “Solutions Depend on the Problem’s Situation” and “Changing Context Requires Changing Solutions” to instead use an excuse of why they are not even going to try certain practices – without having any context of if it is going to work.
    Much of the debates I see are not at the, “Well, we’re being dogmatic about this process we’ve tried. It isn’t working, yet we keep doing it.” It instead is in the realm of, “That idea is insane. It will never work for us. Therefore, I reject it because of X”. For example – pair programming, test-driven development and others fall into this.
    So, yes, I do think the world is more complex than we think, and I do thing we need to be smart about how we adopt these practices. But while that means repurposing practices that aren’t working, it also means trying new things that may seem foreign to us. Timebox them, measure them, whatever, but try them.

  • Arjen Vrielink

    Great post, I think the power of the idea lies in the flexibility of the method itself as opposed to the more traditional agile flexibility in the ‘choice’ of the method. So you could define the ‘traditional’ agile manifesto as ‘a-priori flexibility’ while above manifesto argues for ‘continuous flexibility’ and ‘constant adaptation’.

  • Alek Davis

    You speaketh the words of wisdom. ๐Ÿ™‚ Great post. Thank you.

  • Jeff Anderson

    I usually find your posts insightful, witty, and rewarding.
    Not so with this one.
    Your principles document is essentially a set of “meta-principles” that fundamentally says” anything could be wrong or right but it depends”.
    This kind of thinking is best suited for philosophy class and not for software engineers or any business that actually needs to get something done.
    Yes you need to be open-minded, and yes serving dogma doesn’t do anybody any good.
    But principles, values, ethics are meant to have a broad appeal across a large number of situations, they have to be pursued with passion or else they are meaningless.
    Software development principles and ethics are meant to support developing better software, not communal hugs in large numbers.
    I suppose I could say that your post could be applied to some situations, but not to others, but IMHO that is the same as saying it has no value…
    Sorry but that’s the way I see it.

  • Machiel Groeneveld

    This reminds me of something I’ve read in The Toyota Way. Apparently Western people tend to look for generic principles that apply to everything whereas Japanese people want to know what the best solution is for a particular situation. Of course that’s oversimplified but this could be a reason why the Complex Manifesto doesn’t have a natural appeal to the typical Western person. The problem with these generic principles are that they usually create sub-optimal solutions and tend to come and go fairly quickly.
    I however like this Manifesto because it shakes the ground of any methodology (which includes Agile) and promotes experimenting and tuning practices and processes. Sharing experiences is even more important to keep the IT-memes procreating. Dogmas are like viruses in such a system, trying to change every new idea for it’s own good or destroy it.

  • Hillary Johnson

    Hillary Johnson
    This applies to agile, and pretty much the rest of everything.

  • David Wright

    Nicely said, wish I had written it.
    David Wright

  • Jurgen Appelo

    @Mendelt: Actually I think it’s not values, principles and practices that make such claims. It’s people who do that, when they want to make things look simple.

  • Jurgen Appelo

    @Pawel: I beg to differ. You may have Ron Jeffries’ article, which was literally called “Context, My Foot”.
    My view is “Context is king” and it is directly opposed.

  • Jurgen Appelo

    @Corey: I agree that measurement of results is what counts. Sometimes people reject solutions for very good reasons, other times they don’t know what they’re rejecting. That’s true.
    I would say: let the numbers speak for themselves. All research shows that agile practices show (mainly) successes. So people have some explaining to do when they reject agile practices. But agilists should never dismiss those explanations beforehand.

  • Jurgen Appelo

    Yes, the post is a bit “meta” isn’t it?

  • Jurgen Appelo

    @Jeff: Why is something meaningless when it is not pursued with passion?
    And why does my post have no value? I have a lot of passion for this topic. Therefore (following your reasoning) this post is not meaningless. ๐Ÿ™‚
    Sorry, but I simply cannot follow the logic in your reply. So I don’t know how else to answer it.

  • Jurgen Appelo

    @Michiel: Personally, I think this is what agile is all about.
    Alistair Cockburn once said it something like this: There is only one true agile practice: the retrospective (or… evolve). Everything else should follow from that!

  • Mary

    Ik heb ervan genoten Jurgen. Ik vind je een goed schrijver en kijk er soms met jalouzie naar.
    (in elke bewondering zit nl altijd een beetje afgunst)
    Leuk ook om mijn grijze celletjes hiermee te stimuleren.
    Vele gedachten gaan door mijn hoofd maar laat ik niet filofisch worden en het simpel en praktisch houden: hoe kan ik jouw ‘anti’ prince2 blog in dit kader plaatsen?

  • Jurgen Appelo

    @Mary: Thanks for the nice compliment!
    And yes, I do think there’s even a place in this world for Prince2. Though it might be in the same dark and wet place where the blobfish resides. ๐Ÿ™‚

  • Stephan Okhuijsen

    Excellent read. Got my vote.
    Maybe an additional part can be about the developers, as complex human beings, making things even more complex and thus requiring the right approach for each problem.
    Not all developers are fit for all methods.

  • Henrik Jernevad

    Very nice post!
    Just don’t hold your breath waiting for that “software developers and managers learn to understand that there’s no need to flame each other over methods, frameworks, principles, and practices.” ๐Ÿ˜‰

  • Marek Tihkan

    What else could I say – it’s great post.
    The name of the manifesto should be different in my opinion, maybe “common sense manifesto”. When I read E. Brechner’s book “I. M. Wright’s “Hard Code”” then it seemed to me that we should use more common sense than following blindly some practices. In other words we use it when it works. Same idea you can find from T. Kuhn’s book “The Structure of Scientific Revolutions”. In physics there are different theories/views about same thing (e.g. dualism of light). Sometimes its better to use one theory over other, but it doesn’t make it better theory.


    Ivanildo Falkenstein…signed

  • Angelo Anolin

    Nice article. No wonder this blog is top on my list. It basically encompasses the realms and dynamics and the ever increasing need for change and improvement in software development. Needless to say, this one hits the target….
    And I am pretty sure that a lot of pundits and die hards out there are scratching their heads in disbelief because they feel that their own methodologies / concepts / frameworks are much superior than the others.

  • framakers

    Geez… something I ‘ve always been thinking, summarized in a clear way! You’ve got my vote, provided I may ignore your manifesto when it does not fit my context ;-).

  • Custom Essay

    Thanks, I fully agree wuth your advices. Thanks for making these tips!

  • Toni

    I love the things written under Solutions Depend on the Problem’s Situation. I’m putting up a small business and most of them say to just copy some successful business’ business model, but I disagree with that. a solution that worked for one business may not be applicable to another business. doing the same failed strategy over and over until it succeeds don’t work either.

  • Nick Jenkins

    Just found this and I’m happy to sign up to it, as I was to the Agile Manifesto, and to Context Driven Testing and RAD and a few others – because it shakes the status quo.
    Improvement is always better. Change is nearly always better, it holds the possibility of improvement.
    But now I’m unhappy because once I’ve signed up to it – I want to know what’s next? This is a point in time and now it’s passed – so we need something new please!
    (I often think we need a Zen-Bhuddist approach to agile et al, i.e. “you are correct my child, story card are like requirements – but if this is so, what is the blu-tack?”)

  • Pingback: The Complexity Manifesto vs. Agile Fundamentalism

How to Change the World - freeย Workout - free