In my 20+ years of working with open source software, I have seen lots of things go from simple to advanced to complicated, to then be replaced by something ostensibly radically simpler — which itself then predictably landed on the exact same path of ever-increasing complexity.

I have seen this in three different projects up close, of all of which I have been a heavy user and occasional contributor: Ansible, OpenStack, and Open edX. It just so happens that all these are Python codebases but that does not reflect negatively on Python, and it does not reflect negatively on those projects, their founders, or their developers either: the growth in complexity in software projects is a given. It is not the problem. The problem is that we think we can avoid it.

Now that I am a manager, I see much the same patterns: organizations seek to simplify their architecture, their deployments, even their organizational structure ever further, only to end up with more complex, more complicated, more Byzantine solutions than they ever had before. Managers, who should make it their goal to curb and slow the growth of complexity in their part of the organization, are frequently complexity accelerators, making things needlessly more complicated for everyone.

And even top-level decision-makers, with their quest of distilling everything down to a small number of “simple” metrics on which they can base long-term planning, end up building edifices built on entropic quicksand.

In this talk I highlight the core issue of ever-increasing complexity in non-trivial systems, and the fact that is as inexorable as the passage of time. I identify the special kind of hubris (or well-meaning ignorance) it takes to assume you can wind the clock backwards. And I explain how every one of us can identify things acting as complexity multipliers and people acting as complexity accelerators, and what to do about them.