Quit Simplifying!

venerdì 24 maggio

11:40 - 12:25
Livello audienceIntermediate
Elevator pitch

In this talk, I explain the concepts of complexity and entropy, and how they derail the idea of simplification. I delve into why it is that people, even if they have pure intentions and a great desire to simplify, usually end up doing the opposite. And I give suggestions on what to do about that.


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.

TagsEducation, Distributed Systems, Architecture, Abstractions, DevOps

Florian Haas

I run the Education team at Cleura. I keep a blog, I write on a variety of issues, and I’ve liked and used Python for more than 15 years.