Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Efficiency-Destroying Magic of Tidying Up

florentcrivello.com

Post reply on HN
Print view View original

151–160 of 196 posts

Re: The Efficiency-Destroying Magic of Tidying Up

#151

Post by stefco_ »

TeMPOraL wrote: post #117
chewbacha wrote: post #110

Earlier quoted context omitted.

Sure, but that’s the result of almost 4 billion years of trial and error. I don’t think comparing that to a couple years of engineering trial and error is quite the same :p

Why not? Our brains let us iterate orders of magnitude faster than biological evolution can. It's how we built civilization.

But our chief technical innovation was factoring problems into smaller ones. This is such a vital innovation that it's practically synonymous with engineering. So even superficially complex, organic-looking, highly optimized solutions will need to somehow factor nicely in order for us to be able to keep iterating on them. So in the end, it will have to just be a more clever or elegant factoring of the problem (unless we augment our intelligence in some way that lets us solve much more complex systems without factoring).

Re: The Efficiency-Destroying Magic of Tidying Up

#152

Post by TeMPOraL »

stefco_ wrote: post #151
TeMPOraL wrote: post #117

Earlier quoted context omitted.

Why not? Our brains let us iterate orders of magnitude faster than biological evolution can. It's how we built civilization.

But our chief technical innovation was factoring problems into smaller ones. This is such a vital innovation that it's practically synonymous with engineering. So even superficially complex, organic-looking, highly optimized solutions will need to somehow factor nicely in order for us to be able to keep iterating on them. So in the end, it will have to just be a more clever or elegant factoring of the problem (unless…

I think they do factor nicely, in the design space. Those highly optimized solutions don't appear out of the blue, but from the set of more or less explicit constraints encoded in optimizing software. We can move forward with treating a complex part as an atomic unit, something just fabricated to computer-generated design, and iterate on the set of properties we're interested in.

(Whether that's ultimately a good approach, I don't know. I haven't thought about this too deeply yet.)

Re: The Efficiency-Destroying Magic of Tidying Up

#154

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

Re: The Efficiency-Destroying Magic of Tidying Up

#155

Post by coldtea »

wlesieutre wrote: post #124
coldtea wrote: post #121

Earlier quoted context omitted.

> 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

From the end result described either they didn't try or they weren't successful in doing it. If they did there wouldn't be any changes made to appease the customer.

Re: The Efficiency-Destroying Magic of Tidying Up

#156

Post by CGamesPlay »

basch wrote: post #102
knowaveragejoe wrote: post #50

Earlier quoted context omitted.

There was no first person to escape, there were people who survived the war with the machines and were never "in the matrix" to begin with. You should check out The Animatrix.

MORPHEUS: When the Matrix was first built there was a man born inside that had the ability to change what he wanted, to remake the Matrix as he saw fit. It was this man that freed the first of us and taught us the secret of the war; control the Matrix and you control the future.

At the end of the second movie we learn that this is a creation myth, that Zion is actually part of the larger system of machine control over humanity, and that it needs to be "restarted" periodically. The problem is choice.

Re: The Efficiency-Destroying Magic of Tidying Up

#157

Post by FrankyHollywood »

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…

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

I can feel a bit for it. I have worked on a complex multi-million line codebase. There was this predictible behavior when a new guy came to join us. Many times they had never worked on such a large project.

First they rant about how terrible the system is, than tell us how wrong the system is, followed by advice about how we should use this an this method or design patterns to make things right.

Only after months of working with the code the guy would cool down. When a (software) system is really complex, you have to get familiar with it. No matter how you structure it, a minimum number of logic and dependencies will always exist. Restructuring will not take away the complexity. It's just replacing them.

Offcourse a clear structure is better for you're understanding than a messy one, but even in the most clearly written code a lot of complexity can exist. I think Scott is talking about this, the point beyond clear structure.

thats complexity :)

Re: The Efficiency-Destroying Magic of Tidying Up

#158

Post by usrusr »

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…

While I do wholeheartedly agree with everything you wrote, I still feel need to point out a limitation I don't see (or feel) solved: how do you scale this approach to n>1 developers? In a large brownfield you can assign quasi-solo projects in different corners isolated by sufficiently wide buffers of legacy code you won't touch, but a multi-developer greenfield needs architectural structure simply to give the parallelly written code something to integrate with.

Re: The Efficiency-Destroying Magic of Tidying Up

#159

Post by TeMPOraL »

usrusr wrote: post #158
TeMPOraL wrote: post #76

Earlier quoted context omitted.

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…

While I do wholeheartedly agree with everything you wrote, I still feel need to point out a limitation I don't see (or feel) solved: how do you scale this approach to n>1 developers? In a large brownfield you can assign quasi-solo projects in different corners isolated by sufficiently wide buffers of legacy code you won't touch, but a multi-developer greenfield needs architectural structure simply to give the paralle…

In one of my previous jobs we faced this issue, and we've approached it like this: we would start with a design meeting for a simple solution, divide it up into pieces that can be worked on independently, with agreed-on interfaces. Then each of us would be working independently on their piece, and we'd revisit the design questions as issues cropped up. Is this the best approach? I don't know. But I don't think it's bad.

Re: The Efficiency-Destroying Magic of Tidying Up

#160

Post by dgreensp »

si1entstill wrote: post #148
dgreensp wrote: post #141

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

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

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.

Post reply on HN