“In a Hierarchy Every Employee Tends to Rise to His Level of Incompetence”

Laurence J. Peter The Peter Principle: Why things Always Go Wrong

That’s the hypothesis anyway. More on the Peter Principle.

Recently I learned about the study Promotions and the Peter Principle which supports the hypothesis with empirical evidence. According to the study (on salespeople) the effects are not only measurable, but large.

Like people, code and the software people use tends to get developed – “promoted” – to its level of uselessness. “Incompetence” implies agency; software has only some amount of utility.


In development, any piece of code gets added to as long as addition is reasonably convenient. This process stops when the library or module in question grows to incomprehensibility.

Sometimes code doesn’t reach an incomprehensible state exactly, but becomes so disordered and messy that updates aren’t worth the effort. In eather case, a developer will then write something new instead. The Old library stays in its poor state forever. The software has a sort of activation energy – like chemical reactions – that increases until it becomes inert.

We might begin to quantify the SPP (Software Peter Principle) activation energy threshold by noting the complexity level required to make a rewrite easier than touching the existing code. There’s actually some (messy) data on this in Github and other project hosting platforms to construct at least the appearance of empiricism for such a idea. Once done, we can market a four-tier “SPP Radar” framework for avoiding the need for rewrites. Come on, let’s do it! Can we make it into a book? No? Well it should be good for a conference talk at least. To be serious for a second, I do wonder if project forking has some meaningful connection to project complexity.

Is the SPP a universal law? To be sure, some internal code gets put out of its misery and deleted, replaced by a new library. And the cycle repeats.


Many people have observed software’s tendancy to get more bloated, complex, confusing and slow over time. Microsoft Office provides a classic example. It’s not a recent phenomanon either. This editorial from nearly twenty years ago makes the case. Some of the proposed remedies are quite ironic in hindsight. The author proposed converting office apps into web applications. What he failed to consider is that the Software Peter Principle just keeps on chugging. We now have Office 365 and soon we won’t be able to escape its subscription model.

The “thin client” style apps he proposed are now the norm, and while they’re good for ease of installation they make up for it in downtime and constant feature changes and updates. To be fair, the churn on native app software updates has gotten pretty high recently too but at least you can often decline to update those.

Sticking with the Office theme, I would argue the peak for Microsoft word processors was around Word for Xenix and DOS, and Microsoft Works word processor marked another peak around 2003 or so. For actually producing a lot of human language text it was perfect. I used it on my three NaNoWriMo novels and some other big documents. It counts your words, checks your spelling, formats and styles and otherwise gets out of your way. Word 97 was pretty nice too. Then they added the ribbon.

Examples are too numerous to mention. I wrote about a similar idea before in Everything is Terrible.

Specifically regarding the Peter Principle, the “promotion” by users continues as long as software stays minimally useful. It ends up getting employed for things it’s not really designed for (see Excel) but until the pain gets too bad people persist.