15 ms·

The Efficiency-Destroying Magic of Tidying Up

594 points by cryptozeus 7y ago

Uhuhreally 7y ago
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
- madengr 7y ago
  It was a giraffe, for which that nerve just seems out of place.
- mtts 7y ago
  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 7y ago
    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
- z3t4 7y ago
  Are there any interesting theories? I think a lot can be attributed to just randomness. Some time in the evolutionary process we got infected by a bacteria, the mitochondria is now a vital part in our bodys energy system...
  - gus_massa 7y ago
    One of the nerves that go from the brain to the eye and is hooked by the top part of the aorta artery. In the original version, it was in some animal like a fish, and the top part of the aorta was in the gills, so the way from the brain to the eye though the hole that is below the aorta was a straightforward path. A few million years later, when we lost the gills, and got a neck, the top part of the aorta moved inside the chest to avoid a stupid long trip to the neck and back (and probably lost a lot of speed in the blood). The nerve was hooked, so the aorta got shorter, but the nerve has to go down to the chest, pass below the aorta, and then go back to the eye. In the case of the giraffe, the trip to the chest and back to the eye is stupidly long. The problem with evolution is that mutation can do only small changes (most big changes are just deadly). The connections of the nerve and the artery form very early in the development of the fetus, when it looks almost like an ugly fish. You can't unentangle the nerve and the artery later. More details: https://en.wikipedia.org/wiki/Recurrent_laryngeal_nerve https://en.wikipedia.org/wiki/Recurrent_laryngeal_nerve
AndrewKemendo 7y ago
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.
pasttense01 7y ago
Now we have a reference we can refer people to when they complain about our spaghetti code...
friendlybus 7y ago
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 7y ago
  I think the point he is trying to make is more about “...mistake complexity for chaos, and rush to rearrange it ”
deleted 7y ago
[deleted]
arcdelsol 7y ago
Just like my codebase
carapace 7y ago
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.
- kioieiure 7y ago
  https://www.youtube.com/watch?v=WFQ7Nzlzgbk https://www.youtube.com/watch?v=WFQ7Nzlzgbk
- TeMPOraL 7y ago
  I've been mad at my parents plenty of times for cleaning up my room as a kid for the same reason - even though it might have looked like a mess, everything naturally ended up in the most obvious place for me; a kind of mind-environment feedback loop setting on an equilibrium.
- FooHentai 7y ago
  >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.
solidsnack9000 7y ago
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.
a2tech 7y ago
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).
BlueTemplar 7y ago
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?
- nickbauman 7y ago
  IIRC, they only standardized the interfaces, not the implementations. You could write your team's code any which way you wanted, but you had to expose a consistent REST api in front of it all and publish its specification to the rest of the company.
- foobiekr 7y ago
  If standardized means APIs, yes. If standardized means anything to you about implementation, even at the level of “don’t reimplement what another team - or even another part of your own team - already implemented” then no.
- ReptileMan 7y ago
  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 7y ago
    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...
- quicklime 7y ago
  That's what I was thinking when I read the article. When I worked at Amazon, everyone worked out of the same repo(s), used the same build system (Brazil), deployment system (Apollo), deployed to the same place (EC2), most APIs were written using the same framework (Coral), etc. This is not that unlike the other large tech companies, and now that I'm back at a large non-tech company where everyone builds their own slightly-incompatible tools and deployment pipelines, I do miss that standardization. Sure, some people chose to use different tools here and there, but most people wouldn't choose to reconstruct the universe just to stand up a microservice. It's not like all the "two-pizza teams" were all doing completely different things with incompatible tooling. It's been a while since I worked there, so things might've changed completely since then. But as a shareholder, I hope not.
pmoriarty 7y ago
"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.
- Mirioron 7y ago
  I don't think AI would turn reality into a Rube Goldberg machine, but rather that it would create so much complexity that we can't see through it.
  - basch 7y ago
    The Matrix. I always thought it would be interesting to have a prequel about the first person to escape. Office Space meets X Files, and the order of the complexity slowly becomes more apparent, until the movie turns into Playtime.
    - kyriakos 7y ago
      I am not sure the story suggests a first person escaped. More like there were always some people who never got captured and added to the matrix who freed others.
      - p_l 7y ago
        It's been implied that the machines might have built Zion on purpose. Including freeing first people to live in it in every iteration.
        jacobush 7y ago
        Yes, but I think that is probably a backsplanation from later movies. I you only watch the first (xkcd:566) it felt more like there was a first person escaping.
deleted 7y ago
[deleted]
kioieiure 7y ago
> 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 7y ago
  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 7y ago
    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.
- jacobush 7y ago
  DOS based?
- twic 7y ago
  TopoR: https://en.wikipedia.org/wiki/TopoR#Features https://en.wikipedia.org/wiki/TopoR#Features TopoR, destroy all autorouters: https://wp.josh.com/2017/10/23/adventures-in-autorouting/ https://wp.josh.com/2017/10/23/adventures-in-autorouting/
- rcxdude 7y ago
  Interestingly, I contend that the prevelance of 45 degree angles is in large part due to the capabilities of ECAD software. If you look at old manually-routed PCBs, 45 degree bends are rare. If you try to make a design with non-45 degree bends in most ECAD software, prepare for pain as much of the features of the layout engine fail to work properly (I had experience of this after being inspired by some images of TopoR-designed boards).
rsync 7y ago
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 7y ago
  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.
jsonne 7y ago
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.
dugditches 7y ago
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 7y ago
  That's the first thing that struck me as well; a person like my dad (a retired blacksmith), could make the first one ...
  - Aengeuad 7y ago
    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.
Mathnerd314 7y ago
Joel has a post about working in a bakery: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-... 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 7y ago
  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.
ken 7y ago
> 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.
- madengr 7y ago
  In our tour at work, they show off a 3D printed, computer optimized part. It looks very similar to that tensile structure; ver organic looking. The customer didn’t like the look, and they had to fill in some areas to make it look less alien.
  - coldtea 7y ago
    >The customer didn’t like the look, and they had to fill in some areas to make it look less alien Instead, they should have sold it as more organic and advanced to the customer, and explained why it is so, like the article did... That would gain them even more respect from the customer, whereas now they merely caved in and looked incompetent of getting it right at first (since the customer nows thinks it's his complains that made them finally do it properly).
    - wlesieutre 7y ago
      You're assuming they didn't
TeMPOraL 7y ago
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 7y ago
  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.
- lonelappde 7y ago
  The drones are messy because they have ugly messy human bodies. The ships are highly patterned and repetitive.
daguar 7y ago
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!)
- mtts 7y ago
  Have an upvote. By coincidence I just read Scott’s book not too long ago and can attest that it contains not a single suggestion that imposing any sort of order on a system is ever a good idea. Quite the opposite, in fact. There may be lessons for city planners and agriculturalists in the book, but I’m pretty sure there isn’t a single one for software developers.
  - lonelappde 7y ago
    Au contraire. The world wide web is justified by Scott's book. As is JavaScript and the crazy things we do with it. Worse is Better. Understanding how distributed systems actually work beyond how we wished they work.
- cookiecaper 7y ago
  > 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
paganel 7y ago
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/1 https://twitter.com/jo_liss/status/674332649226436613/photo/...? [2] https://en.wikipedia.org/wiki/Neuf-Brisach#/media/File:Neuf-Brisach_007_850.jpg https://en.wikipedia.org/wiki/Neuf-Brisach#/media/File:Neuf-...
ilovecaching 7y ago
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.
rdiddly 7y ago
Hmm, point taken. And yet, legibility is itself valuable and efficient too.
pizzaparty2 7y ago
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.
- dionian 7y ago
  Often true, but often 'beautiful code' does not impact the bottom line - even in the long term.
  - afpx 7y ago
    It does if it’s a requirement for keeping employees from quitting.
    - vkou 7y ago
      I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists. I can, however, imagine quitting if my manager is a shitty person. People don't quit work - they quit managers.
      - wpietri 7y ago
        I think this is a fine attitude in the short term, and an absolutely terrible one in the long. It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low. But I think it's also bad for the developer. Giving up and accepting bad code and low productivity means we develop habits and attitudes appropriate to that environment. It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches. And given how our industry keeps changing, I think that's a recipe for disaster.
WesternStar 7y ago
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.
nickysielicki 7y ago
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 7y ago
  Unorganized at first glance, right? And yet a tree (on average) is perfectly balanced in terms of weight distribution around the trunk.
daseiner1 7y ago
> both these algorithms and nature are optimizing for efficiency. nature certainly doesn’t optimize for “efficiency”
keithnz 7y ago
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 :)
m0zg 7y ago
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 7y ago
  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 7y ago
    Ditto testability. For most messy code I’ve cleaned up, no one could say if it worked correctly. (Spoiler: no.)
lugg 7y ago
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.
zelly 7y ago
Great refutation of functional programming.
ratel 7y ago
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 7y ago
  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.
nroets 7y ago
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 7y ago
  The Karatsuba algorithm was found before Schönhage-Strassen.
jimnotgym 7y ago
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 7y ago
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.
zzo38computer 7y ago
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.)
dgreensp 7y ago
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 7y ago
  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 7y ago
    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.
shishircc 7y ago
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.
billti 7y ago
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.
pure-awesome 7y ago
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-like-a-state/ https://slatestarcodex.com/2017/03/16/book-review-seeing-lik...
PeterStuer 7y ago
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 7y ago
  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.
- jazzdev 7y ago
  Isn't the trend in cities for more mixed-use space? And wouldn't Uber be more profitable if people lived and worked in different parts of the city?
erezsh 7y ago
> 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..
christiansakai 7y ago
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.
deleted 7y ago
[deleted]

594 points by cryptozeus 7y ago

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

madengr 7y ago
It was a giraffe, for which that nerve just seems out of place.
mtts 7y ago
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 7y ago
  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
z3t4 7y ago
Are there any interesting theories? I think a lot can be attributed to just randomness. Some time in the evolutionary process we got infected by a bacteria, the mitochondria is now a vital part in our bodys energy system...
- gus_massa 7y ago
  One of the nerves that go from the brain to the eye and is hooked by the top part of the aorta artery. In the original version, it was in some animal like a fish, and the top part of the aorta was in the gills, so the way from the brain to the eye though the hole that is below the aorta was a straightforward path. A few million years later, when we lost the gills, and got a neck, the top part of the aorta moved inside the chest to avoid a stupid long trip to the neck and back (and probably lost a lot of speed in the blood). The nerve was hooked, so the aorta got shorter, but the nerve has to go down to the chest, pass below the aorta, and then go back to the eye. In the case of the giraffe, the trip to the chest and back to the eye is stupidly long. The problem with evolution is that mutation can do only small changes (most big changes are just deadly). The connections of the nerve and the artery form very early in the development of the fetus, when it looks almost like an ugly fish. You can't unentangle the nerve and the artery later. More details: https://en.wikipedia.org/wiki/Recurrent_laryngeal_nerve https://en.wikipedia.org/wiki/Recurrent_laryngeal_nerve

AndrewKemendo 7y ago

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.

pasttense01 7y ago

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

friendlybus 7y ago

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 7y ago
I think the point he is trying to make is more about “...mistake complexity for chaos, and rush to rearrange it ”

deleted 7y ago

[deleted]

arcdelsol 7y ago

Just like my codebase

carapace 7y ago

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.

kioieiure 7y ago
https://www.youtube.com/watch?v=WFQ7Nzlzgbk https://www.youtube.com/watch?v=WFQ7Nzlzgbk
TeMPOraL 7y ago
I've been mad at my parents plenty of times for cleaning up my room as a kid for the same reason - even though it might have looked like a mess, everything naturally ended up in the most obvious place for me; a kind of mind-environment feedback loop setting on an equilibrium.
FooHentai 7y ago
>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.

solidsnack9000 7y ago

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.

a2tech 7y ago

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).

BlueTemplar 7y ago

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?

nickbauman 7y ago
IIRC, they only standardized the interfaces, not the implementations. You could write your team's code any which way you wanted, but you had to expose a consistent REST api in front of it all and publish its specification to the rest of the company.
foobiekr 7y ago
If standardized means APIs, yes. If standardized means anything to you about implementation, even at the level of “don’t reimplement what another team - or even another part of your own team - already implemented” then no.
ReptileMan 7y ago
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 7y ago
  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...
quicklime 7y ago
That's what I was thinking when I read the article. When I worked at Amazon, everyone worked out of the same repo(s), used the same build system (Brazil), deployment system (Apollo), deployed to the same place (EC2), most APIs were written using the same framework (Coral), etc. This is not that unlike the other large tech companies, and now that I'm back at a large non-tech company where everyone builds their own slightly-incompatible tools and deployment pipelines, I do miss that standardization. Sure, some people chose to use different tools here and there, but most people wouldn't choose to reconstruct the universe just to stand up a microservice. It's not like all the "two-pizza teams" were all doing completely different things with incompatible tooling. It's been a while since I worked there, so things might've changed completely since then. But as a shareholder, I hope not.

pmoriarty 7y ago

"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.

Mirioron 7y ago
I don't think AI would turn reality into a Rube Goldberg machine, but rather that it would create so much complexity that we can't see through it.
- basch 7y ago
  The Matrix. I always thought it would be interesting to have a prequel about the first person to escape. Office Space meets X Files, and the order of the complexity slowly becomes more apparent, until the movie turns into Playtime.
  - kyriakos 7y ago
    I am not sure the story suggests a first person escaped. More like there were always some people who never got captured and added to the matrix who freed others.
    - p_l 7y ago
      It's been implied that the machines might have built Zion on purpose. Including freeing first people to live in it in every iteration.
      - jacobush 7y ago
        Yes, but I think that is probably a backsplanation from later movies. I you only watch the first (xkcd:566) it felt more like there was a first person escaping.

deleted 7y ago

[deleted]

kioieiure 7y ago

> 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 7y ago
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 7y ago
  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.
jacobush 7y ago
DOS based?
twic 7y ago
TopoR: https://en.wikipedia.org/wiki/TopoR#Features https://en.wikipedia.org/wiki/TopoR#Features TopoR, destroy all autorouters: https://wp.josh.com/2017/10/23/adventures-in-autorouting/ https://wp.josh.com/2017/10/23/adventures-in-autorouting/
rcxdude 7y ago
Interestingly, I contend that the prevelance of 45 degree angles is in large part due to the capabilities of ECAD software. If you look at old manually-routed PCBs, 45 degree bends are rare. If you try to make a design with non-45 degree bends in most ECAD software, prepare for pain as much of the features of the layout engine fail to work properly (I had experience of this after being inspired by some images of TopoR-designed boards).

rsync 7y ago

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 7y ago
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.

jsonne 7y ago

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.

dugditches 7y ago

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 7y ago
That's the first thing that struck me as well; a person like my dad (a retired blacksmith), could make the first one ...
- Aengeuad 7y ago
  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.

Mathnerd314 7y ago

Joel has a post about working in a bakery: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-... 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 7y ago
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.

ken 7y ago

> 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.

madengr 7y ago
In our tour at work, they show off a 3D printed, computer optimized part. It looks very similar to that tensile structure; ver organic looking. The customer didn’t like the look, and they had to fill in some areas to make it look less alien.
- coldtea 7y ago
  >The customer didn’t like the look, and they had to fill in some areas to make it look less alien Instead, they should have sold it as more organic and advanced to the customer, and explained why it is so, like the article did... That would gain them even more respect from the customer, whereas now they merely caved in and looked incompetent of getting it right at first (since the customer nows thinks it's his complains that made them finally do it properly).
  - wlesieutre 7y ago
    You're assuming they didn't

TeMPOraL 7y ago

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 7y ago
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.
lonelappde 7y ago
The drones are messy because they have ugly messy human bodies. The ships are highly patterned and repetitive.

daguar 7y ago

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!)

mtts 7y ago
Have an upvote. By coincidence I just read Scott’s book not too long ago and can attest that it contains not a single suggestion that imposing any sort of order on a system is ever a good idea. Quite the opposite, in fact. There may be lessons for city planners and agriculturalists in the book, but I’m pretty sure there isn’t a single one for software developers.
- lonelappde 7y ago
  Au contraire. The world wide web is justified by Scott's book. As is JavaScript and the crazy things we do with it. Worse is Better. Understanding how distributed systems actually work beyond how we wished they work.
cookiecaper 7y ago
> 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

paganel 7y ago

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/1 https://twitter.com/jo_liss/status/674332649226436613/photo/...? [2] https://en.wikipedia.org/wiki/Neuf-Brisach#/media/File:Neuf-Brisach_007_850.jpg https://en.wikipedia.org/wiki/Neuf-Brisach#/media/File:Neuf-...

ilovecaching 7y ago

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.

rdiddly 7y ago

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

pizzaparty2 7y ago

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.

dionian 7y ago
Often true, but often 'beautiful code' does not impact the bottom line - even in the long term.
- afpx 7y ago
  It does if it’s a requirement for keeping employees from quitting.
  - vkou 7y ago
    I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists. I can, however, imagine quitting if my manager is a shitty person. People don't quit work - they quit managers.
    - wpietri 7y ago
      I think this is a fine attitude in the short term, and an absolutely terrible one in the long. It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low. But I think it's also bad for the developer. Giving up and accepting bad code and low productivity means we develop habits and attitudes appropriate to that environment. It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches. And given how our industry keeps changing, I think that's a recipe for disaster.

WesternStar 7y ago

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.

nickysielicki 7y ago

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 7y ago
Unorganized at first glance, right? And yet a tree (on average) is perfectly balanced in terms of weight distribution around the trunk.

daseiner1 7y ago

> both these algorithms and nature are optimizing for efficiency. nature certainly doesn’t optimize for “efficiency”

keithnz 7y ago

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 :)

m0zg 7y ago

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 7y ago
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 7y ago
  Ditto testability. For most messy code I’ve cleaned up, no one could say if it worked correctly. (Spoiler: no.)

lugg 7y ago

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.

zelly 7y ago

Great refutation of functional programming.

ratel 7y ago

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 7y ago
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.

nroets 7y ago

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 7y ago
The Karatsuba algorithm was found before Schönhage-Strassen.

jimnotgym 7y ago

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 7y ago

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.

zzo38computer 7y ago

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.)

dgreensp 7y ago

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 7y ago
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 7y ago
  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.

shishircc 7y ago

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.

billti 7y ago

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.

pure-awesome 7y ago

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-like-a-state/ https://slatestarcodex.com/2017/03/16/book-review-seeing-lik...

PeterStuer 7y ago

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 7y ago
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.
jazzdev 7y ago
Isn't the trend in cities for more mixed-use space? And wouldn't Uber be more profitable if people lived and worked in different parts of the city?

erezsh 7y ago

> 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..

christiansakai 7y ago

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.

deleted 7y ago

[deleted]