Live data from Hacker News

The Efficiency-Destroying Magic of Tidying Up

florentcrivello.com

121–130 of 196 posts

Re: The Efficiency-Destroying Magic of Tidying Up

#121
post #41
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…

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.

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

Re: The Efficiency-Destroying Magic of Tidying Up

#122
post #119

Earlier quoted context omitted.

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

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

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.

Re: The Efficiency-Destroying Magic of Tidying Up

#123

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

Code, at least the way we currently write it, is a fundamentally lossy transfer. The coder has the context in their head; they understand what's happening up to that point, what they want to happen now, and what needs to happen later. Writing code is translating those concepts and ideas into a specialized step-by-step list of machine instructions.

In the course of writing the concepts in a dumbed-down format for an instruction machine, context is inevitably lost. You can say "write comments" until you're blue in the face, but it doesn't solve the problem.

Then, someone new comes along, and they don't understand the context, they never knew anything about it before, and you quit 8 months ago. This person must infer the context and determine an accurate conception of the context from the pieces left behind.

The approach taken when one finds themselves in that position is one of the key tells of their skill and experience IMO. Regardless, it seems that if the software got out of the loose demo/messing around phase, it deserves at least some consideration before it's dismissed out of hand as "bad code".

Re: The Efficiency-Destroying Magic of Tidying Up

#124
post #41

Earlier quoted context omitted.

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.

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

You're assuming they didn't

Re: The Efficiency-Destroying Magic of Tidying Up

#125
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?

Re: The Efficiency-Destroying Magic of Tidying Up

#126
post #125

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

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.

Re: The Efficiency-Destroying Magic of Tidying Up

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

The OP explicitly mentions Chesterton’s Fence.

Re: The Efficiency-Destroying Magic of Tidying Up

#129
post #128

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.

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

Re: The Efficiency-Destroying Magic of Tidying Up

#130

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

The article does not imply that chaos is inherently good or efficient.

When I look at big, 'good', codebases, I'm always amazed at how much complexity there is at every level, and wonder why it can't all just be clean and orderly.

The trade off between performance, bureaucratic code and leaky abstractions seems to be ever-present.

I can never make an API 'fit' that elusive ideal of what it should be, there are always bits of dangling weirdness.

Try for example doing anything in Unicode; it's as though there are permanent grey areas and ambiguities. There's always the corner case that someone, somewhere in some corner of the world will either break it, or be without the ability to 'spell their name' or whatever.

I don't think this is about arbitrarily crap code.

Post reply on HN