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

71–80 of 196 posts

Re: The Efficiency-Destroying Magic of Tidying Up

#71

Post by mtts »

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…

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.

Re: The Efficiency-Destroying Magic of Tidying Up

#72

Post by andy_ppp »

pizzaparty2 wrote: post #53

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…

I actually think having business people who have control over what programmers do is the mistake very often. It leads to very bad decisions for the codebase as a whole and the programmers often don’t know the best way to fit in the random business needs because they are never told why the feature should exist. I think we need a better method to be able to make the right decisions for the code while still achieving the desired outcomes without making quite such a mess. Maybe something like sessions where the business has to persuade the developers to build the features in detail rather than throwing random unclear solutions over the fence and saying we need this.

Re: The Efficiency-Destroying Magic of Tidying Up

#73

Post by CPLX »

pmoriarty wrote: post #10

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

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

How would that be distinct from actual reality?

Re: The Efficiency-Destroying Magic of Tidying Up

#74

Post by btbuildem »

nickysielicki wrote: post #63

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

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

Re: The Efficiency-Destroying Magic of Tidying Up

#75

Post by mlyle »

TeMPOraL wrote: post #57
pizzaparty2 wrote: post #53

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…

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

> It could be viewed instead as an argument against "architecture astronautics", the "15 layers of abstraction to print 'hello world'" school of software design.

It's a long way from printf to framebuffer pixels. There's good reasons for every layer inbetween, too. (I like C compilers, format strings, buffered I/O, I like file descriptor semantics; I like having an operating system and it providing terminal emulation and framebuffer text rendering services!)

So I'm fine with 15 layers of abstraction to print hello world.

Re: The Efficiency-Destroying Magic of Tidying Up

#76

Post by TeMPOraL »

wpietri wrote: post #64
TeMPOraL wrote: post #57

Earlier quoted context omitted.

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

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 to writing the simplest thing that works). Rinse, repeat. It's not about rushing to release barely working pile of spaghetti, but recognizing that programming is an exploratory activity, and you don't know enough to do complete design up front.

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

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

Re: The Efficiency-Destroying Magic of Tidying Up

#77

Post by TeMPOraL »

mlyle wrote: post #75
TeMPOraL wrote: post #57

Earlier quoted context omitted.

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

> It could be viewed instead as an argument against "architecture astronautics", the "15 layers of abstraction to print 'hello world'" school of software design. It's a long way from printf to framebuffer pixels. There's good reasons for every layer inbetween, too. (I like C compilers, format strings, buffered I/O, I like file descriptor semantics; I like having an operating system and it providing terminal emulation…

It's 15 layers in the system; I was talking about 15 extra layers in your own code, introduced up front, before any meat has been written.

I'm not saying abstraction is bad - just that it's constraining, and prematurely introducing a whole ladder of constraints is going to grind code evolution to a halt.

Re: The Efficiency-Destroying Magic of Tidying Up

#78

Post by uulu »

pizzaparty2 wrote: post #53

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…

Strange, how did you come to the conclusion that this is a defense of "crap code"? For one thing - crappy code is most often less efficient than elegant code.

Re: The Efficiency-Destroying Magic of Tidying Up

#79

Post by rcxdude »

hazeii wrote: post #25
kioieiure wrote: post #13

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

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.

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.

Re: The Efficiency-Destroying Magic of Tidying Up

#80

Post by d0mine »

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…

I see it more like a rigid grid architecture vs. organically build/evolved structures like in the book "A Pattern Language: Towns, Buildings, Construction" by Christopher Alexander et al.

Here's some pictures https://medium.com/design-matters-4/a-new-approach-to-design...

Post reply on HN