From Complexity Theory to Practical Management

One day I realized that software projects are complex adaptive systems, just like brains, beehives, biological cells, birthday parties, and the tiny ecosystems under my armpits on a hot sunny day. Of course, I wasn't the first with that notion. Ken Schwaber and Jim Highsmith referred to complex adaptive systems in their books on agile project management, and these guys are just a few out of many. But the references have always been casual, addressing concepts like emergence and self-organization, and little else. So, in order to have a much deeper understanding of software projects, and the seemingly never-ending discussions that we face in our business every day, I decided that I first needed to understand the theory.

So, what the hell is a complex adaptive system anyway?

Well, I turned to Complexity Theory –the study of complex systems– which coincidentally happens to be the successor of Chaos Theory. I bought and read almost every book I could find on the subject, both popular and scientific. I struggled through The Quark and the Jaguar and Hidden Order, wrecked my brains on Complexity: Life at the Edge of Chaos and Signs of Life, and ruined my eyes on several other books that tried to make me see the wonders of complex adaptive systems. Being just a simple software developer, I understood only half of it. And I chided myself for not having befriended any math students in my earlier days. Fortunately, some books were more forgiving, and quite accessible for the average computer science graduate. Books like At Home in the Universe, Complexity: The Emerging Science at the Edge of Order and Chaos, The Tipping Point, Chaos: Making a New Science and Out of Control are examples of great works that did not just open my wallet, but my eyes as well.

But understanding alone does not make a solution.

I had acquired knowledge of complexity theory, and I wanted to translate that to problems and discussions in software development. But how? There is so much to tell people about nonlinearity, feedback loops, phase transitions, power laws, self-organized criticality, reductionism, performance systems, fitness landscapes, and the edge of chaos… But where do I start? And even more important… Do people care?

I have been pondering on this issue for six months.

It was while reading the fantastic book Presentation Zen that I realized how to proceed. I should not be telling people how interesting complexity theory is, and what we might learn from it. (This would probably just get me arrested for death by boredom.) What I should do is to try and find some Laws of Software Projects… the things that are always true, or should always be made true. These laws should be presented as a clear and concise message, one that directs people in solving their day-to-day problems, and guiding them in their discussions. Sure, I will need to refer to complexity science. But the theory needs to be presented as a supporting background. Not as an intimidating close-up.

As the target audience I aim for people who need to manage software development activities, either directly or indirectly. This will include project managers, but I also hope to spark some interest among development managers. And as every employee knows: the further up the chain, the simpler a message needs to be. Some of my readers might even be VP's or CIO's, which means that each message should almost be elevator-pitch-sized (and accompanied with fancy pictures, buzz words and bar charts).

Practical management with complexity theory is what I'm after. And if you're interested then there's just one thing I ask you to do… Keep reading!

Note: This post is published automatically while I'm sipping on a cocktail on a beach in Cuba. I will respond to any replies and comments, but it might take a while.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
A Theory of Everything for Software Development
Complex versus Complicated
The Cone of Incompetence