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

Accidentally Load Bearing

jefftk.com

Post reply on HN
Print view View original

131–140 of 204 posts

Re: Accidentally Load Bearing

#131

Post by gav »

bamfly wrote: post #46
TheCapn wrote: post #28

Huh. Finally a name for it. I do a lot of support work for Control Systems. It isn't unheard to find a chunk of PLC code that treats some sort of physical equipment in a unique way that unintentionally creates problems. I like to parrot a line I heard elsewhere: "Every time Software is used to fix a [Electrical/Mechanical] problem, a Gremlin is born". But often enough when I find a root cause of a bug, or some sort o…

This is why I comment a "why" for any line of code that's not incredibly obvious. And 100% of the time when it's due to interaction with something outside the codebase, whether that's an OS, filesystem, database, HTTP endpoint, hardware, whatever, if it's not some straightforward call to some API or library. Sleep due to rate limiting from another service? COMMENT. Who's requiring it, the limits if I know exactly wha…

I like to make sure the "why" is documented, but it's hard to get people to care about that.

I remember a former client tracking me down to ask about a bug that they had struggled to fix for months. There was a comment that I'd left 10 years earlier saying that while the logic was confusing, there was a good reason it was like that. Another developer had come along and commented out the line of code, leaving a comment saying that it was confusing!

Re: Accidentally Load Bearing

#132

Post by mhink »

mauvehaus wrote: post #73
letitbeirie wrote: post #38

Earlier quoted context omitted.

The most haunting comment line I've ever seen was buried deep in an Allen Bradley PLC: > I don't know why this rung is needed but delete it and see what happens for yourself Did not fuck around; did not find out.

Context for those who haven't worked in the field: A PLC is a programmable logic controller. They are typically programmed with ladder logic which grew out of discrete relay based control systems. Generally they're controlling industrial equipment of some sort, and making changes without a thorough understanding of what's happening now and how your change will affect the equipment and process is frowned upon. https:/…

I interned briefly at a company which mainly built industrial control systems. One of its most interesting features (which is also very mind-bending if you're coming from any sort of typical programming ecosystem) is that every "rung" is evaluated in parallel. (As a physical relay-based control system would have back in the day.)

Very wild stuff.

Re: Accidentally Load Bearing

#133

Post by jefftk »

hinkley wrote: post #128
jefftk wrote: post #95

Earlier quoted context omitted.

For what it's worth, in the Boston area traditional sheathing is boards parallel to the ground, not diagonal. (I've seen dozens of houses from ~1900-1920 in the process of full gut rebuilds, and none of them had diagonally installed sheathing.)

It might be more of a commercial building thing than a domestic construction one. I know I've seen it in a number of videos of renovations of larger buildings, including barns. I might have the time range off. Big cities are full of 1920's constructions especially on the West Coast, and they don't do that. My old house (~1920) had diagonal shiplap under the floors instead of plywood (but parallel in the oldest walls)…

The subfloors I've seen for old houses in Boston are also laid perpendicular to the joists, though diagonal does seem like it would make more sense.

Re: Accidentally Load Bearing

#134

Post by HeyLaughingBoy »

TheCapn wrote: post #28

Huh. Finally a name for it. I do a lot of support work for Control Systems. It isn't unheard to find a chunk of PLC code that treats some sort of physical equipment in a unique way that unintentionally creates problems. I like to parrot a line I heard elsewhere: "Every time Software is used to fix a [Electrical/Mechanical] problem, a Gremlin is born". But often enough when I find a root cause of a bug, or some sort o…

> "Every time Software is used to fix a [Electrical/Mechanical] problem, a Gremlin is born".

Just did one of those this morning. Hmmm.

Re: Accidentally Load Bearing

#135

Post by sam_bristow »

overnight5349 wrote: post #123
hef19898 wrote: post #90

Earlier quoted context omitted.

No, why? The point was EEs and MEs, or rather traditional engineering heavy culture produces bad software (never mind the first software devs tended to be EEs), so Juicero is good example of a software-leaning culture producing shitty hardware products.

Uh, the Juicero was spectacular hardware. The mechanical engineering in that beast was absolutely beautiful. I don't recall what the software was like, but none of that is why it failed, it was simply a moronic business idea. An overpriced subscription for low quality fruit in a DRM-laden pouch. Nobody wanted it then or now.

I kinda want a Juicero now, but only as an object d'Art. It was a garbage product.

Re: Accidentally Load Bearing

#136

Post by tetha »

mostlylurks wrote: post #112
MrBuddyCasino wrote: post #83

Earlier quoted context omitted.

You're doing the lords work. I often get pushback on doing this with some variation of "comments bad, code should be self-documenting". This is unwise, because there are "what code does" and "why code does" comments, but this turns out to be to nuanced to battle the meme.

Self-documenting code is perfectly capable of expressing the "why" in addition to the "what". It's just that often the extra effort and/or complexity required to express the "why" through code is not worth it when a simple comment would suffice.

> Self-documenting code is perfectly capable of expressing the "why" in addition to the "what".

I don't think anymore that's true, at least in a number of areas.

In another life, I've worked on concurrent data structures in java and/or lock-free java code I'd at this point call too arcane to ever write. The code ended up looking deceptively simple and it was the correct, minimal set of code to write. I don't see any way to express the correctness reasoning for these parts of code in code.

And now I'm dealing with configuration management. Code managing applications and systems. Some of these applications just resist any obvious or intuitive approach, and some others exhibit destructive or catastrophic behavior if approached with an intuitive approach. Again, how to do this in code? The working code is the smallest, most robust set of code I can setup to work around the madness. But why this is the least horrible way to approach this, I cannot express that in code. I can express this in comments.

Re: Accidentally Load Bearing

#137

Post by weaksauce »

letitbeirie wrote: post #38
TheCapn wrote: post #28

Huh. Finally a name for it. I do a lot of support work for Control Systems. It isn't unheard to find a chunk of PLC code that treats some sort of physical equipment in a unique way that unintentionally creates problems. I like to parrot a line I heard elsewhere: "Every time Software is used to fix a [Electrical/Mechanical] problem, a Gremlin is born". But often enough when I find a root cause of a bug, or some sort o…

The most haunting comment line I've ever seen was buried deep in an Allen Bradley PLC: > I don't know why this rung is needed but delete it and see what happens for yourself Did not fuck around; did not find out.

do you remember what the instruction was?

Re: Accidentally Load Bearing

#138

Post by weaksauce »

TheCapn wrote: post #56
ke88y wrote: post #51

Earlier quoted context omitted.

> I do a lot of support work for Control Systems. It isn't unheard to find a chunk of PLC code that treats some sort of physical equipment in a unique way that unintentionally creates problems. I like to parrot a line I heard elsewhere: "Every time Software to fix a [Electrical/Mechanical] problem, a Gremlin is born". At least some of this is cultural. EEs and MEs have historically viewed software less seriously than…

You're not wrong. It shows in the state of PLC/HMI Development tools. Even simple things like Revision Control is decades behind in some cases. I've basically found my niche in the industry as a Software Engineer though I can't say I see myself staying in the industry much longer. The amount of time's I've gotten my hands on code published by my EE coworkers only to rewrite it to work 10x faster at half the size with…

> It shows in the state of PLC/HMI Development tools.

i mean you are talking about upgrading things that are going to be in service for decades perhaps. the requirements for the programs is generally not complicated. turn on a pump for a time, weigh something and then alarm if some sensor doesn't see something.

Structured text was an improvement over ladder logic as you could fit more of the particular program in the screen real estate you had and could edit it easier since it was just text. though, that had its own set of issues that needed to be worked through and it wasn't a panacea.

Re: Accidentally Load Bearing

#139

Post by perrygeo »

w10-1 wrote: post #84

This article and every other comment seems to miss the real issue: the lack of testing. Software differs from all other means of production in that we can in fact test any change we make before realizing it in the world. With good tests, I don't care what the intent was, or whether this feature has grown new uses or or new users. I "fix" it and run the tests, and they indicate whether the fix is good. With good tests…

test developers? test departments? QA teams? It's worth mentioning that the vast majority of software orgs don't have the luxury of such distinctions, i.e. software teams are generally directly responsible for the quality of their own work and can't punt problems across the org chart.

Re: Accidentally Load Bearing

#140

Post by w0mbat »

praptak wrote: post #129
letitbeirie wrote: post #38

Earlier quoted context omitted.

The most haunting comment line I've ever seen was buried deep in an Allen Bradley PLC: > I don't know why this rung is needed but delete it and see what happens for yourself Did not fuck around; did not find out.

This has the "more magic" anecdote feel to it. http://www.catb.org/jargon/html/magic-story.html

I remember reading a story like this from the early days of Acorn. The first production sample of the BBC Micro came in, and would crash unexpectedly. Trial and error found that connecting a jumper wire between 2 particular points on the board stopped it crashing, but nobody could work out why it crashed or how that fixed it. They never worked it out and ended up shipping mass quantities of the BBC Micro with the magic jumper wire in place on each one.
Post reply on HN