The Efficiency-Destroying Magic of Tidying Up

Post by kixiQu » Mon, Nov 18, 2019, 9:10 PM UTC

cookiecaper wrote: post #120

daguar wrote: post #45

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

> 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 s…

Post by yellowapple » Mon, Nov 18, 2019, 9:44 PM UTC

TeMPOraL wrote: post #76

wpietri wrote: post #64

Earlier quoted context omitted.

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…

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…

Post by lonelappde » Mon, Nov 18, 2019, 9:55 PM UTC

anon73044 wrote: post #172

xondono wrote: post #165

Earlier quoted context omitted.

The other point I find missing is that this kind algorithmic optimization tends to miss solutions that are quite obvious to "system designers" due to local maxima (evolutionary roadblocks). For instance, nature has not figure out how to evolve wheels even in flat regions.

Counter point: the tumbleweed. Also, you're assuming that wheels are the most efficient design for traveling, but bullions of dandelions seem to spread their seeds every year along with dozens of other plants.

Post by lonelappde » Mon, Nov 18, 2019, 10:11 PM UTC

TeMPOraL wrote: post #44

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 seemin…

Post by tikiman163 » Mon, Nov 18, 2019, 10:33 PM UTC

TeMPOraL wrote: post #49

ken wrote: post #36

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

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.