A perfect mess

by Nikolai Bonderup

I was recently reminded of the book A Perfect Mess - The Hidden Benefits of Disorder - How Crammed Closets, Cluttered Offices, and On-the-Fly Planning Make the World a Better Place by Eric Abrahamson and David H. Freedman after I read the following thread by Ginger Bill (whos real name I dont know), the creator of the programming language Odin:

Most people who say want they to "organize their code" actually mean they want to "taxonomize their code". People want to give "structure" to things, even if that structure provides not actual use. They have learnt that "structure is good" and therefore think any kind is "good".

I think this is part of why things like OOP became popular. OOP, especially the traditional inheritance style, provides a way to "structure" code, and it's a pattern that can be applied everywhere.

The problem is that that approach to structuring code is not necessary good.

And especially with the inheritance approach, it becomes 100% a taxonomization of the code rather than any form of organization. It might be a "structure" but again, why would that be good thing a priori?

With other forms of OOP, especially with more structural-typing approaches (sorry for the confusing terminology) or type-classes/trait/interface systems, they do have a different form of "structure" which people can just keep applying everywhere.

But are those practically good?

And as I have been implying, people think "structure" and "taxonomies" are equivalent to "organization".

The actual organization of code is unfortunately a hard thing to do/generalize, and depends on a per-project basis.

It's a skill that comes with experience & actually thinking about what organization actually is rather than naïvely applying "structure" everywhere.

Now I think the reason this conflation happens is mostly due to the "masculine brain" which likes to systematize things, and when this is put to the extreme, it has been argued that this is a psychological basis of autism (see Simon Baron-Cohen's research on the E-S Theory).

I am NOT trying to argue that everyone who does this is autistic (not in the slightest) but rather it is a pattern of thinking that is akin to it, and quite natural for a lot of "masculine brained" individuals to fall into.

The question now becomes, how do we "combat" this natural urge a lot of programmers have? How do we kind of tell them to "think flat" first and then see the patterns that arise from the code.

And when the patterns arise, then "organize" those patterns; not around the patterns.

I am not under the impression that A Perfect Mess is a very popular book, as I have only heard about it through Nassim Talebs book Antifragile, so I will give a quick summary here of the main point. The core message of A Perfect Mess is simple: disorder is not a failure, or typically, inefficient. A surprising amount of “mess” is not only harmless, but actively efficient. Trying to force everything into neat systems often wastes more time than it saves, because real life—and real work—rarely fits into perfectly organized schemes (essentially reductions). A messy setup can be faster to use, easier to adapt, and closer to how things actually function in practice. The problem is that you, by employing some organisational scheme, try to reduce the world into a model that is simpler than the problem you actually have — and in doing so, you often create more complexity than you remove. Like fitting a square peg into a dinosaur shaped hole - while you might make it fit, it certainly won't be easy.

In programming we talk a lot about “clean architecture”, “proper layering” and “good structure”. But just like in A Perfect Mess, where a bit of disorder turns out to be both normal and useful, I suspect a lot of our obsession with tidy codebases is mostly aesthetic. We chase purity and patterns, even when they don’t actually help the program do its job - even in cases where they might actually make the program worse.

Ginger Bill’s writing on pragmatism in programming hits the same nerve: a program is there to solve a specific problem, not to realize a grand abstract model. Once you go generic, you lose information about the specific; once you go “purely structured”, you often lose sight of the data and the machine. This article is my attempt to connect those ideas: to argue that much of what we call “organization” in software is just taxonomy, and that we should care less about structure in the abstract and more about the actual problem in front of us.

It is generally foolish to hunt for some sort of purity that will nenver exsits.

Once you go generic, you lose information about the specific

This deals with the law of specificity. A program is general and not generic. Design for the specifc case you have, not the general case you dont have.

I think we are too obsessed with the idea of "structure" and "organization" in the software development world.

The issue is that too much organisation is usually idealistic. it removes us from the realities of programming for an actual computer and an actual use case, and instead focuses on some totally tertiary value that is not essential to the problem and operation of the program.

I don't thin there is anything wrong with organizing code. I just think it can often be a waste of time. Spending large amoutns of time suffling declariations and such provides no value.

A simple example: imagine a small tool that reads a CSV file, filters a few rows, and writes a new file. In one version, everything lives in a single file with three clear functions: read_input, filter_rows and write_output. The file is 300 lines long, and you can scroll through it in a minute and see the whole data flow.

Now imagine the same tool "properly structured": we split it into InputModule, OutputModule, FilterEngine, a RowProcessorFactory, interfaces for each of those, and a ToolApplication class to wire them together. We add folders like Core/Domain/Application/Infrastructure, dependency injection, and a pile of indirection. The behavior is identical, but the user gets no extra value from any of this.

In a tiny program like that, the real "organization" is just: Can I quickly see where the data comes from, what happens to it, and where it goes? Once that is clear, whether the code lives in one file or ten, or whether it follows some textbook layering pattern, is mostly irrelevant. The extra ceremony is just a tax you pay every time you read, navigate, or change the code.

This is what I mean when I say that a lot of "code structure" is taxonomization rather than true organization. Past a certain point, you are just shuffling functions and files so that the structure looks "clean" according to an abstract model, instead of making the program easier to understand, change, or run.

People I speak to usually find this argument for being less organised nonsense. I think it is a combination of them being indoctrinated by the idea of "clean code" and other such ideologies.

It is usually countered with some argument about not organising your code into some taxonomy will make it less readable, and therefore worse code. In a sense, they argue that it will become "spagetti" code.

A lot of modern programming advice tries to remove the details and make thigns a lot more generic.