
The Efficiency-Destroying Magic of Tidying Up - cryptozeus
https://florentcrivello.com/index.php/2019/09/04/the-efficiency-destroying-magic-of-tidying-up/
======
ken
> When computers design things, they look very different.

Yes, because the computer assumes they're not going to change. The "tensile
structure" looks cool now, but throw it in the back of a truck for 3 months
and see if it's still algorithmically perfect. Parts get beat up. Tabs get
bent a little. Maybe we'll want to grind off one of those tabs that we're not
using because it's in the way, or weld on a new one. With the old structure, I
can see which parts are relevant to maintaining the integrity of the system.

It looks like an un-optimized binary, which is very close to its source code.
That's a feature. I can reason about the parts on their own.

The "topologically optimized" one is like an optimized binary. It's great for
saving a few grams as long as you never have to change anything. The downside
is that it's impossible to reason about. If one tab gets a little bent, that
may be harmless, or it may cause the entire structure to lose its strength.
You don't know.

Similarly, the truss on the catwalk over the crazy-looking Wendelstein 7-X is
made of nice even rectangles and right triangles, and I guarantee that's not
because it's a topologically optimal shape for this truss.

~~~
TeMPOraL
There are ways to make such "organic" structures more resillient. _Life_ is
one huge proof of that. One of the reason biologists and medical researchers
have so much trouble figuring how anything works in living organisms is
because in biology, there are very few clear boundaries; every process is
mixed up with a lot of other ones. And yet the final result is incredibly
resilient.

~~~
sean2
Sure, but there's some downsides to that. If a part in my car fails, the
mechanic pulls it out and bolts in a new one without much consideration for
the rest of the system. If a part of my body fails, there's a slim chance I
might be able to get a replacement from another person, and I'll have to be on
immuno-supressents for life, and very expensive people will be needed to
perform the installation, and things often go wrong even so.

The house I'm living in has been around 30+ years, but in the last 5 years,
I've witnessed several trees in the yard die.

I guess what I'm saying, is there is a trade off between easy to understand
and fix (orderly) and resiliency(biological), and even then I see a lot of
orderly things outlast the chaotic systems.

~~~
TeMPOraL
A good point, and cars are a perfect example. Older cars tend to be less
efficient than new ones, but there was a point in time not too long ago when
you could repair anything in your car with a welder, some elbow grease, and a
free afternoon. New cars of today tend to require expensive somewhat expensive
specialists to fix, and I've been hearing that the future is in cars that
refuse to start unless the ECU can cryptographically verify that each and
every part is authentic - that's like an immune system of sorts, except one
that isn't protecting your car, but the manufacturer's ability to take your
money. Unfortunately, it seems that more and more complex products are heading
this way.

~~~
microcolonel
> _New cars of today tend to require expensive somewhat expensive specialists
> to fix_

Not for any practical reason. The tolerances on _some_ parts are tighter, but
in general anyone who takes the same interest that the average man took in the
'80s can repair the vast majority of a current vehicle, safely, as long as
they're not deliberately impeded by a computer.

~~~
TeMPOraL
> _as long as they 're not deliberately impeded by a computer_

But I meant exactly that - at least from the stories I hear (I don't own a new
enough car), half of the breakage in modern cars seems to require interfacing
with the computer to at least clear an error flag. I once helped a guy with a
software project, and learned that he's operating a workshop fixing a specific
car brand. He showed me the device he uses to interface with the computer, and
explained to me how the official software costs such ridiculous amounts of
money that he instead hired some Chinese company that would remote-connect to
his laptop and do some trickery to keep the software work without the license.
Neither official nor the "unofficial" route seems to me to be accessible to a
regular car owner.

~~~
lsc
>half of the breakage in modern cars seems to require interfacing with the
computer to at least clear an error flag.

Yes, you need an odbII tool. they are not expensive by the standards of decent
'80s automotive tools (the cost of 'minimum viable analog tools' has dropped
precipitously during my lifetime. )

The cheapest ODBII tools are bluetooth, and there is a cornucopia of apps to
interface with them in the app store. You can get one that is easier to use
that doesn't require a phone for $100 that will work for most problems on most
cars.

(Of course, the more expensive ODBII tools are better, I'm given to
understand, and allow you to do more, but you can do a _lot_ with the cheap
junk; and resetting the codes is generally the most basic functionality;
unless you've got a fancy car, even the cheapest one that fits your brand
should work for that. )

Having come of age at a time when I was driving and repairing (older)
carberuated vehicles, I personally think that fixing a carb is like a thousand
times harder than interfacing with the ODB system. Modern injection systems
just solve so many problems without trying.

My experience of the modern diagnostic systems is that it's actually way
easier. The scan tool saves you so much time and effort vs. the old manuals
"go to page 5 if it doesn't X, 32 if it does" A lot of the time, the cheap
scan tool gives you a code and description; you punch that into a search
engine and you get a goddamn video of someone doing the repair. It's _amazing_
compared to screwing around with an exploded parts diagram. (I mean, from the
perspective of someone who isn't really a car guy) - I mean, there's always
problems the scantool doesn't catch, but... I mean, I'm talking about all this
from a shadetree perspective, there have _always_ been a lot of automotive
problems I couldn't fix, just 'cause I'm not an automotive specialist.

~~~
nradov
An ODBII is helpful for basic stuff but it doesn't get you very far with
modern cars. Most manufacturers now have specialized proprietary scanners
which are needed for any complex repairs, especially for anything electronic.
Those scanners are extremely expensive and sometimes only sold to authorized
service centers.

~~~
fragmede
Are these manufacturers called BMW, by any chance? They sell this authorized
"computer module" replacement part for $400. But if you take it apart, there's
a 50 cent fuse inside that was blown. Replacing the fuse does no good without
access to the proprietor BMW software, because the module will refuse to work
after the fuse is replaced until it is reset using their software. Which means
you have to pay for a whole new module. However not all manufacturers are like
that. After I change the oil on my Honda, there's a silly little dance to
reset the oil life indicator, but nothing too crazy. The Toyota Corolla is a
favorite for self-driving car enthusiasts due to the hackability of its lane-
guidance system into something fuller. I'm also disappointed in some of the
directions the future has taken us (it's frustrating to me how hard it is the
replace user-servicable parts inside a lot of laptops, eg Apple), but not all
manufacturers are the same and talking about the situation as if they are is
too abstract to be useful, say, when looking for your next car.

------
daguar
I think I have to quibble with this:

> Here, I propose Scott’s Law: never put order in a system before you
> understand the structure underneath its chaos.

James C. Scott wouldn't probably _never_ underwrite re-ordering of systems
from the top down.

Central to his argument is that viewing complex systems from any singular
position requires a process of simplification (legibility) that prevents a
complete understanding.

The _presumption_ that one has gotten to a place of "understand[ing] the
structure underneath [the] chaos" is in fact the false confidence he
attributes to most of these ordering projects.

I think if you want to wrangle a suggestion from Scott's book, it's more about
making lots of small pokes at a system and seeing how it reacts, and slowly
building on positive reactions from the system.

(Also, messiness and complexity are not intrinsically linked to the efficiency
of a system — systems can optimize for lots of variables and it's really
context-specific. So as much as you shouldn't take order to be innately good,
don't take messy to be innately efficient!)

~~~
cookiecaper
> Here, I propose Scott’s Law: never put order in a system before you
> understand the structure underneath its chaos.

Previously formulated as Chesterton's Fence [0], among others.

There's definitely a blind spot in software for the general principle that you
should understand a thing well before you decide to remove it. Anyone want to
propose some theories on why disregard for an extant body of work tends to
plague software so extensively?

[0] [https://www.chesterton.org/taking-a-fence-
down](https://www.chesterton.org/taking-a-fence-down)

~~~
kixiQu
Because we suffer from the attitude that we don't have to understand a thing,
as, say, reading the article might lead to, before attempting to correct it.
;)

~~~
cookiecaper
It wasn't really intended as a correction -- more just an addition -- but I
didn't feel like clarifying just to save a few imaginary internet points.
Apologies to anyone who interpreted as attempting to correct an article I
didn't even read. :)

------
TeMPOraL
Incidentally, I think the producers of Star Trek nailed this with design
language of the Borg, perhaps accidentally.

For those who don't know, the Borg are a machine intelligence hive mind
species that roams the galaxy in their cubes, spheres, diamonds and other
ships shaped like basic solids, destroying or assimilating anything
interesting in their path, and speaking a lot about "bringing order to chaos".
Yet seemingly despite their focus on order and perfection, the individual
drones and the microstructure of the ships both look like a haphazard bundle
of lights and wires. This is in line with the article - machine intelligence
optimizing for extreme efficiency across multiple dimensions isn't going to
create sleek-looking constructs.

~~~
yellowapple
I suspect it ain't all that accidental. Each Borgship behaves (ostensibly) as
a single giant organism (and the Borg within it its cells), and multicellular
organisms are indeed pretty messy inside, even if they look externally simple
and uniform.

------
PeterStuer
I'm a 'lover of chaos'. My working desks always gather strata of documents,
more often than not disheveling onto the surrounding floor.

This article however rubs me the wrong way right from the start. 'Cars running
at the same speed' aren't "efficiency-destroying" nor about spurious
'appearance'. A controlled laminar flow is incredibly more efficient than
chaotic turbulence.

It does not get any better later on, when the author waxes lyrically about
'beautiful equilibrium that evolved to satisfy a thousand competing
constraint' in the absence of planning, casually glossing over the part where
communal zoning regulation prevents not just externality dumping races to the
bottom and the basis for non-speculative investment to those that can't afford
to gamble or force their own "manu militari" regulation.

While self proclaiming "not suggesting all chaos is good", it is exactly what
the rest of the article's suggestive language tries to convey. The
deregulation agenda, while not explicitly spelled out, is omnipresent in the
tenure of the writing.

P.S. I'm not surprised to learn that the author works for Uber.

~~~
Crashbat
Very well said, and I think you've hit the nail on the head with regards to
the 'deregulation agenda'. The subtext of articles like this is always that
interference, in the form of regulations, is a negative action, and by
stripping away the messy human meddling we'll reap the rewards. It's never
considered that the human meddling is so often done to protect the humans
themselves, most often the very weakest or most powerless.

------
pizzaparty2
Sorry but there's no excuse for crap code. If it's hard to understand then
time is lost every time you have to work with it.

You shouldn't defend it by trying to assign positive attributes to it (its
effecient. ...yeah). Maybe there's nothing good about bad code and we should
use being called out on it as an opportunity for improvement.

No, lets double down on our delusions of superiority by telling ourselves that
crap we wrote is somehow effecient in some way.

Im tired of it. Its not effecient. Its bad and you should feel bad.

~~~
TeMPOraL
When applying this article to code, I don't think it has anything to do with
spaghetti being good. It could be viewed instead as an argument against
"architecture astronautics", the "15 layers of abstraction to print 'hello
world'" school of software design.

~~~
wpietri
Exactly. I remember being called into consult on an accounting system for
microfinance; the target audience was small to medium-sized. The code had an
absurd amount of layering; one path I traced copied the data 8 times from
fetch to render, each time into a different set of objects that had basically
the same fields, but that were conceptually different.

When I asked about this, I was told it was "best practice" and that if they
ever needed to scale, there were now many places they could separate things. I
pointed out that for the target audience, they probably wouldn't need to
scale. But that if they did, it would be because they were doing 7x the work
necessary.

The code was certainly "tidy" from the perspective of the guy who got paid a
lot of money to produce architecture diagrams. But it was a nightmare from the
perspective of an individual programmer trying to add a feature. They would
have been way better off without a lot of quasi-religious design theory
slowing them down.

~~~
TeMPOraL
I used to write code like that - architecting whole application up front,
creating layers upon layers of abstractions. Experience taught me to do the
reverse now - start with the simplest version that works, keep going until
writing code gets tough, and then switch to whiteboard and use what I learned
along the way to design a proper solution (and if any part of the design
process starts getting tough, I switch back to writing the simplest thing that
works). Rinse, repeat. It's not about rushing to release barely working pile
of spaghetti, but recognizing that programming is an exploratory activity, and
you don't know enough to do complete design up front.

And really, it turns out most of the time that not only you don't need the
complex abstractions designed early on, you actually need a set of different
ones. That's why keeping the design process continuously grounded in reality
is important.

My solution for not producing spaghetti code with this method? I don't release
the first version that works. I don't mark the ticket as "done", and I don't
even push it out of my local repo. Instead, I clean it, or even straight up
rewrite it, until it reaches a sleek and acceptably elegant state. It's the
responsibility of a programmer to decide when the code is ready, and it
doesn't have to be at the first moment it passes all the tests.

~~~
BurningFrog
Maybe the most astonishing thing I've learned in my career is that it's far
better to design your system _after_ the code is written and working!

Because that's the time when you've learned to understand the problem, and you
already have working code to move around.

~~~
crdoconnor
This, absolutely. The time to design properly isn't before you write code.
It's when the requirements start to become fixed rather than fluid.

------
dgreensp
I'm loving these intelligent criticisms of the article.

My own biggest beef with the article is it entirely misses the deep point of
Marie Kondo's work, which is about efficiency and joy. If the article is not
actually a response to her philosophy and definition of tidiness, and just
needed a cute title, well, that's confusing at the very least. The commenters
who point out that codebases, for example, need to be reasonable for humans to
work in, or that it sure is easier to change source code than a compiled
binary, are on the right track.

Kondo's method is all about identifying the clutter _that is actually
clutter_, and deleting it. Would you rather maintain a program that's 1000
lines, or 100? If the 1000-line program was written by you, for you, over the
course of your life, and by your own admission is extremely messy and
moderately unpleasant to deal with, containing lots of unused stuff, yet you
run it, and modify it, every day, no one is going to force you to clean it up,
but you can find joy in doing so.

~~~
si1entstill
Based on the content, it seems to be primarily a clever title. I don't think
the author is trying to refute a hypothetical group of engineers who are
trying to apply Marie Kondo's philosophy to software. (Not that there aren't
devs who are doing that, but that doesn't seem to be the author's goal.)

~~~
dgreensp
This made me smile (“refute a hypothetical group of engineers...”). But even
if the author is not refuting Kondo’s methods specifically, is the author not
saying that acts of intentional tidying should be viewed with skepticism for
putting form over function? When Kondo’s approach is a perfect counterexample
of the claim that decluttering is putting aesthetics over efficiency.

Actually, I think this article is not about software at all, or decluttering a
room, it’s about “ complex systems — like laws, cities, or corporate
processes,” and then uses the word “systems” as shorthand for this, and then
talks a bit about managing software projects but it’s really still about good
corporate process, and then mentions tidying a room but mostly as a joke.

I think the actual point is more about large groups of people or organisms
that function well together, and how you shouldn’t assume it is better to
impose uniformity. Even then, though, it is easy to argue both sides of this
point, pick apart the examples given in the article, and use a codebase as an
analogy to an organization.

------
solidsnack9000
This article makes some good points. In particular, it emphasizes
understanding why there is a “mess” in the first place — appreciating the role
of things in a functioning system is an important step forward to any kind of
constructive change.

Some elements of Konmari’s method actually are consonant with that, since
evaluation of your self and the place of objects in your life are a continuous
part of the process. Just throwing all your stuff away every week, whether you
need it or not, would definitely be efficiency destroying although it would
also be very tidy. Speaking from experience, however, this is not a behavior
that developers struggle with. The heedless piling up of trash, code and
tickets is far more common.

------
pmoriarty
_" When a God-level AI takes over in a science fiction book, it often remakes
the world in its image: full of straight lines, smooth acceleration rates, and
lots of chrome (AIs love that stuff). But as we start using algorithms to
design things, we get results that look a lot more chaotic than that..."_

It would be interesting to see a movie where an AI takes over and turns
reality in to a Rube Goldberg machine.

~~~
api
Huge corporations and governments are kind of like hybrid silicon/meat AIs and
that's exactly what they've done. I think this is the most likely outcome.

~~~
lmm
No, corporations and governments flatten and simplify everything until they
can understand it. The next step, once we have powerful enough systems, is to
embrace the chaos and use it.

E.g. older houses were hand-built, but nowadays houses are built with straight
walls and standardised heights for everything so that mass-produced furniture
can fit in them. But if in the future our furniture is made on-demand by AIs,
then there's no reason to do it that way; you can have a non-standard height
for your kitchen counter (for example) and if/when your dishwasher breaks, the
AI system will fabricate you a new non-standard dishwasher to go under it.

~~~
foobiekr
I work for a large size corporation but one which is a quarter the size of
many fortune 100s. I guarantee you almost no one knows how things work or are
done beyond their immediate scope. Much of my life is spent just trying to
glean an understanding of some adjacent function or trying to convince people
above me that things they believe about how things work are not actually
reflective of how they actually work.

A Rube Goldberg machine usually accomplishes one task. Corporations at scale
don’t resemble them mostly because, as there are a multitude of concurrent
tasks in flight, the Rube Goldberg machines are neither complex nor absurd
enough.

~~~
rini17
Maybe that's how Musk's ventures are different - he knows how everything in
his corporation works?

~~~
TeMPOraL
I think the primary difference is that for Musk, his companies are actual
means to a non-monetary end (electrification of transport, Mars colonization).
This creates a tremendous levels of focus. Most companies exist to make money
for their owners, and any actual useful work done is only a side effect.

------
dugditches
I mean that image of the 'before/after 'topological optimization' seems like a
poor analogy.

>confirming that our intuitive preference for “straight line” designs has
nothing to do with performance

As the first is made to be made because of its 'straight lines'. You can see
the welds and logic in it, as something easily made.

While the second is something only achievable via 3D-Metal printing or
possibly very complex 5 axis CNC.

~~~
Ensorceled
That's the first thing that struck me as well; a person like my dad (a retired
blacksmith), could make the first one ...

~~~
Aengeuad
It's for that reason that I consider the first one to be the more efficient
and 'chaotic' design despite the straight lines. It's optimised for
production, repair or replacement in the field using nothing but metal stock,
a welder, saw, and a drill, or indeed can be manufactured by hand by a
blacksmith. It screams form over function.

------
ratel
This article is wrong on so many levels:

1\. Theoretical: chaotic and complex are not the same thing. Organized and
tidy are neither the opposite from or excluding complex systems. Some very
tidy systems can still be mind-boggling complex. Furthermore Chaotic systems
have a single underlying order (it might just be impossible to discern), but
they are not complex. Complex systems might have multiple orders, none at all
or everything in between.

See for an in-depth discussion: The Collapse of Chaos; Discovering Simplicity
in a Complex World, Jack Cohen & Ian Stewart, Penguin, 2000.

2\. Practical: The amount of tidiness in a complex system does not say
anything about its efficiency, but neither does its untidiness. Complex
systems might be untidy through sunken costs, like most cities are,
revolution, evolution, historical accident, or even attempts to make an
ordered system (like a system of law) always leaving some gap. The fact that a
complex system exists does not say anything about it being efficient or its
fitness for purpose. Like the three year old who thinks the mess is beautiful,
but cannot find her favorite plush toy.

Changing complex systems is indeed hard, because different subsystems will
interact, have feedback loops, create externalities, exclude external
information or are near impossible through sunken costs. But that still leaves
the calculation of how much the new system or altered system might be more
efficient or better than the current system and what the risks involved are.

Tiding up complex systems has risks, but also benefits even if you don't
believe the second law of thermodynamics applies to human created systems.
Tidied up systems are more easy to reason about and thus can be more easily
fixed, adapted or expanded upon. The act of tiding up has the additional
benefit of adding to our knowledge about how a system actually works.

3\. This guy works for Uber. The cab company _with a computer_ that wants to
uproot the current (complex) systems and replace it with something simpler.
Yet fails to turn a profit. Do we need to read something into this article, or
did he just not realize he contradicts his employers mission?

~~~
rossdavidh
All true, and I would also add a lesson from software design. Spaghetti code
might, in some limited sense, be more efficient in some cases, but it is
difficult to understand, therefore difficult to fix when something is wrong.
Making things orderly, even from a top-down perspective, may be more important
than being as efficient as possible, if you need to be able to understand
what's happening in order to use (or fix) whatever it is.

------
carapace
I once cleaned up my sister's room. I thought I was doing her a favor but she
was mad at me for a week! In hindsight I should have known better. Spacial
memory and all that, she knew where everything was even though it looked
messy.

The article is not talking about the kind of tidiness that is the hallmark of
a well-run workshop, IMO. That kind of tidiness is part of what makes more
efficiency in that context.

~~~
FooHentai
>Spacial memory and all that, she knew where everything was even though it
looked messy.

This is something my wife and I have figured out over time - If it's your own
space and nobody else uses it, it's fine to descend to 'chaos' because you can
just remember where you last put something.

That model breaks if the space is occupied by more than one person, because
where one person put something isn't witnessed by the other person. So, having
designated places for things and returning them to their 'home' makes the
space most usable by multiple people.

Personally, even for solo spaces, I still favor everything having a home
because I don't have a good memory for where things were placed.

------
Mathnerd314
Joel has a post about working in a bakery:
[https://www.joelonsoftware.com/2005/05/11/making-wrong-
code-...](https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-
wrong/)

His idea is that there is a pretty high standard of cleanliness in a bakery,
just not the obvious one. A similar "hidden rule" presumably applies to cities
etc.

~~~
NoodleIncident
I'm almost certain I've read this article before, but I think I've read a lot
more about types since then. In particular, this line is hilarious:

> I’m using the word kind on purpose, there, because Simonyi mistakenly used
> the word type in his paper, and generations of programmers misunderstood
> what he meant.

It sure doesn't sound like Simonyi was the one making a mistake here! It
sounds like Hungarian notation is what you use to _compensate_ for missing
types; it got its bad reputation from people using it for types that the
language already provides, because that's easier.

------
m0zg
I strongly disagree with this. Software should not be written to suit the
machine. Software should be written to accommodate the weakest link: humans
who are going to need to figure it out 6 months from now when its current
programmer departs for the greener pastures. If there's no rhyme or reason to
it, it fossilizes immediately and costs a lot of money to rewrite (often into
another fossil). So whatever effort you spend to reduce complexity and
cognitive load, will pay for itself several times over. As a rule of thumb,
the hallmark of a good system is when your guesses about how something would
be done are right almost 100% of the time. You don't arrive in this state by
accident.

~~~
FooHentai
Yep. What this article skips over is _maintainability_ in all of the things it
discusses, and in most cases also flexibility.

The optimization it praises only has single focus (operational efficiency),
whereas if you take into account all of the aspects of the things in question,
suddenly you see that the way things are are usually a solid compromise
between the aspects it's really optimizing for. That includes human
interactions such as analysis, repair, modification, and so on.

~~~
specialist
Ditto testability. For most messy code I’ve cleaned up, no one could say if it
worked correctly. (Spoiler: no.)

------
keithnz
1\. I'm sending this link to my partner to justify my messiness, not sure she
will buy into it... but....

2\. It's not too surprising given the way ntural selection finds efficiencies
in quite complex structures. But trying to reason about how they work is
tricky. When engineering things, being able to reason about a system is often
a lot more important than that system being close to maximally efficient. Main
point is, I think you should always be aware of what trade offs are you
making.... much like my point #1, if you use this to justify being messy, then
it's probablly the wrong tradeoff, but shhh, my partner doesn't read this :)

------
rsync
Clutter and tidying is simply a time debit/credit ledger.

If you had unlimited time, you would tidy and organize everything _in real
time_. However, we don't have unlimited time and so we borrow time from the
future by leaving things slightly messy.

The behavior to avoid, as in money ledgers, is not _using the ledger_ but
never paying it back.

~~~
vlasev
You gain back some efficiency by cleaning up all in one go at a later time!
Think of trips to the sink with the dirty dishes.

------
a2tech
Like all things, everything in moderation. Excessive clutter is choking and
restricts the creative and productive workflow. Allowing yourself the room to
make a mess while in a project though lets you work without constraints. Also
I find myself tidying when I'm trying to avoid a problem. Which can be a
waste, or an opportunity for your mind to work on a problem while your hands
are busy (like a shower thought).

------
paganel
Very interesting examples provided in the article, the "topological
optimization" one [1] made me think of the Vauban fortifications. As can be
seen from even a cursory look on the dedicated Wikipedia page they're mostly
pretty symmetrical and especially well-organized, as can very well be seen for
the Alsatian town of Neuf-Brisach [2]. I'm wondering if the "ideal" solution
for the problem Vauban was set out to solve (protecting towns against
artillery fire) isn't a lot more less symmetrical, like in that topological
optimization example where the "ideal" AI-found solution is a lot more
"messy".

[1]
[https://twitter.com/jo_liss/status/674332649226436613/photo/...](https://twitter.com/jo_liss/status/674332649226436613/photo/1)?

[2] [https://en.wikipedia.org/wiki/Neuf-
Brisach#/media/File:Neuf-...](https://en.wikipedia.org/wiki/Neuf-
Brisach#/media/File:Neuf-Brisach_007_850.jpg)

------
friendlybus
Author mistakes order for purity. The end of excessive purity is the same
storyline as aquaman. The dichotomy of chaos and order is still helpful.

~~~
cryptozeus
I think the point he is trying to make is more about “...mistake complexity
for chaos, and rush to rearrange it ”

------
AndrewKemendo
I learned this by observing wear patterns, in foot traffic routing these are
called "desire paths."

You can also see them in wear patterns on old handles and stairs.

Hence why I think before you try and change a system it's important to know
what your baseline outcomes are and then instrument the system to measure
where these "desire paths" exist in complex systems like computing.

------
jsonne
I really like this article. Certainly makes me think about my own biases
towards "straight lines" as the most "efficient" way of doing a job.

------
BlueTemplar
Hmm, I thought that Amazon was famous for how they standardized their cross-
company software? (With AWS as a side effect.) Or is this not the case
anymore?

~~~
ReptileMan
They didn't standardize the software, they standardized that all software
should be accessible by API and that all software should be designed in such
way to be openable to third party users if need arises.

~~~
BlueTemplar
Right, the right way to do standardization! It a shame that the author didn't
add this very specific requirement though - some readers might think that the
interfaces should be messy too...

------
ilovecaching
Our industry is woefully ignorant of human psychology. We also invest very
little in understanding qualitative improvements in software systems - as
engineers we don't like anything we can't readily measure.

Anyone familiar with the magical number seven knows that systems need to be
simple not for the sake of the computers, but for the sake of the people who
work on it. As much as we like to think of ourselves as geniuses, at the end
of the day we're animals with a finite amount of brain power. We cannot grasp
large complex systems, and we _need_ compartmentalization and simplicity so we
can keep building on top of what we already have.

Maybe one day the computers will take over programming for us, but that day
isn't today.

------
kioieiure
> _London 's tube map only uses 45° angles to aid its human readers. Now can
> you see the humanness in mainboard design?_

What was that russian electronic board design software where nothing is
vertically/horizontally aligned, no trace is straight?

~~~
hazeii
Don't about the russian software, but for any high-speed PCB design the trace
layout matters and 90-degrees bends are to be avoided. On motherboards you'll
often see lines that have an extra squiggle or two to equalise the length (and
thus delay) because they happened to have a shorter distance to cover.

~~~
rcxdude
Mostly 90-degree bends are avoided (in preference to two 45-degree bends)
because it makes the routing easier or because it looks better to the person
doing the layout. If you are operating with high-enough speed signals that a
90-degree bend is a problem you are also avoiding layer changes and many other
things like the plague.

------
nroets
Take a moment and consider the quest to find the fastest multiplication
algorithm. For millennia, we used the classical method. (Shift and add. 3
lines of pseudo code)

Then, along came Fast Fourier Transform based algorithms.

~~~
pfdietz
The Karatsuba algorithm was found before Schönhage-Strassen.

------
erezsh
> Streets arranged in grids, people waiting in clean lines, cars running at
> the same speed…

Grids make it easier to navigate for humans, to plan for public transport, and
improves the city's connectivity.

Waiting in clean lines reduces the chances of fighting in the queue.

Cars running at the same speed dramatically reduces the chances of a lethal
impact.

And what exactly is the cost of these things? Is a grid that much harder to
make? Does anyone want to cancel the dedicated highway, or let cars stop in
the middle of it?

I think this author just doesn't understand the concept of efficiency at all.

> “Please clean up your room,” asks the mother. “Fool,” retorts the three-
> year-old with an eerily deep voice. “Can’t you see the beauty in my glorious
> chaos?”

Sounds like he's still upset about that..

------
nickysielicki
I wrote the following:

> Symmetry underlies almost everything in mathematics and nature.

> It's much more reasonable to assume that our computer programs are not yet
> good enough to recover that symmetry, than to take the output of current
> programs as some sort of evidence that asymmetry itself is some sort of
> ideal.

And then I looked out my window at a tree without leaves, between two
buildings, and I'm looking at how unorganized the branches look, and I'm not
so sure anymore. It's like the "spherical chickens" joke.

(Sidenote: it's incredible how angry and volatile this comment section is ---
my original comment included. Seems this subject can really strike a personal
nerve in many of us. Why?!)

~~~
btbuildem
Unorganized at first glance, right? And yet a tree (on average) is perfectly
balanced in terms of weight distribution around the trunk.

------
shishircc
Both messiness and orderliness have their own place in work.

I find that to be particularly true when you are starting to experiment with
some product or solution. At that time, you need to be messy (hacking a
solution). The need initially is ability to quickly move in trying ideas and
discarding ones that don't work.

Then you reach a time when you have figured out a very elegant solution that a
user of product would just love. At this time, it is right opportunity to
optimize for legibility and orderliness (refactoring) before your solution
turns into a mess that works very well but no one can understand or update.

------
WesternStar
Does it follow from this that while you could train a large machine learning
program to do a task then separating it from a monolith into separable parts
would be highly unlikely to be successful? For example,you could train an
algorithm that does object identification and then train an algorithm that
does object boundary identification considering only the red value in a given
photo from the original large program. However if you start with the
components of an object identifier you might not be able to reach SOA or at
least those two methods would look very different.

------
zzo38computer
Chaos is not necessarily so bad, and order is not necessarily so good. Many
people thing it is and they are wrong. I think even Principia Discordia
mention such thing, isn't it?

And yet, many people today don't like C and assembly language, and hate "goto"
and some other stuff like that, but I think that it is good.

(Also I do not always clean the stuff, because where it is, I know where it is
and do not have to move it again when using it again.)

------
jimnotgym
Struggling to remember, but aren't the 45 degree bends on a circuit board
something to do with etching them consistently? In a lot of electronics the
board is optimised for RFI, or trying to have the lowest inductance (necessary
for passing high frequencies). The grid pattern is optimised for cheap
assembly.

I think the author may be wrong here, and actually the pattern is how it is
for very complex reasons.

------
ineedasername
I just started playing Opus Magnum and so this article resonated with me. In
playing, I've found myself throwing out all optimization on the three metrics
used: component cost, speed, and size.

Instead, I've been designing for aesthetics, for symmetry or clean lines or
linear solutions. When I've given in to the desire to chase the metrics, the
results have been much messier in appearance.

------
billti
I spent much of today doing some woodwork in the garage, and due to its
untidiness, probably spent as much time looking for various tools as I did
using them. (Not to mention tripping a time or two).

Working in a large code base that has little structure/consistency is another
example of high cost/friction.

There is some benefit to organization.

------
daseiner1
> both these algorithms and nature are optimizing for efficiency.

nature certainly doesn’t optimize for “efficiency”

------
christiansakai
Its funny how my mom always told me to clean my room where I see her own room
as messy. It seems that efficiency and tidyness is also in the eyes of the
beholder.

------
pasttense01
Now we have a reference we can refer people to when they complain about our
spaghetti code...

------
rdiddly
Hmm, point taken. And yet, legibility is itself valuable and efficient too.

------
zelly
Great refutation of functional programming.

------
pure-awesome
Scott Alexander wrote up a review of this book on Slatestarcodex. At over
11'000 words it's pretty hefty and goes quite in-depth.

[https://slatestarcodex.com/2017/03/16/book-review-seeing-
lik...](https://slatestarcodex.com/2017/03/16/book-review-seeing-like-a-
state/)

------
arcdelsol
Just like my codebase

------
lugg
This is a strawman argument. And I wish people would stop relegating this type
of system refactoring to some idiotic attempt to institute order for the sake
of order.

Tidying systems up so they are organised "from my perspective" is not done,
"for my benefit". It's done to make things easier to change.

Yes, it can make things less performance, no, most of the time that is
irrelevant.

Refactoring is not optimisation. They are different things and both need to
happen.

They both require you to make trade offs against future difficulties.

------
Uhuhreally
this reminds me of that time blowhard Richard Dawkins disected an animal
(can't remember which) and proceeded to bang on about how stupid the vagus
nerve is, wandering all over the place as it does for no apparent reason.
People used to say the same of the appendix and adenoids; that they're
pointless vestiges, the blindness of evolution, contingent structures. Dawkins
said obviously the nerve should simply connect directly instead of following
its ancient evolutionary program up and down and around the organs.

A classic case of Chesterton’s Fence

~~~
mtts
He said it would have been stupid had someone designed it that way but given
that it evolved it made perfect sense why it was the way it was.

~~~
Uhuhreally
he said it was understandable why it was the way it was but implied that it
"would be better" if it went directly - his tone was scoffing

