Live data from Hacker News

Accidentally Load Bearing

jefftk.com

51–60 of 204 posts

Re: Accidentally Load Bearing

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

> 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 electrical and mechanical systems. As a result, engineering cultures dominated by EEs/MEs tend to produce shit code. Inexcusably incompetent software engineering remains common among ostensibly Professional Engineers.

Re: Accidentally Load Bearing

#52
post #51
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…

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

On the other hand there was Juicero...

Re: Accidentally Load Bearing

#53
post #37

I had something similar. A couple of years ago I bought on old house. The previous owners did most of the work themselves from the 1960s on. The zinc gutter had leaked for probably decades and it destroyed part of the roof structure. The roof was held up by the wooden paneling the used to cover it on the inside (70s). So the wooden paneling was actually load bearing Actually I've found way more stuff in this house. F…

Degrees away from load bearing paint!

Or a poster!

Re: Accidentally Load Bearing

#54

I had something similar. A couple of years ago I bought on old house. The previous owners did most of the work themselves from the 1960s on. The zinc gutter had leaked for probably decades and it destroyed part of the roof structure. The roof was held up by the wooden paneling the used to cover it on the inside (70s). So the wooden paneling was actually load bearing Actually I've found way more stuff in this house. F…

I had a house that had really bad termite damage and the contractor called it "structural stucco".

Re: Accidentally Load Bearing

#55
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 to fix a [Electrical/Mechanical] problem, a Gremlin is born".

I think I get the gist, but that sentence is missing some words.

Re: Accidentally Load Bearing

#56
post #51
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…

> 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 less bugs? Yikes. HMI/PLC work is almost like working in C++ at times, there's so many potential pitfalls for people that don't really understand the entire system, but the mentality by EE/ME types in the industry is to treat the software as a second class citizen.

Even the clients treat their IT/OT systems that way. A production mill has super strict service intervals with very defined procedures to make sure there is NO downtime to production. But get the very same management team to build a redundant SCADA server? Or even have them schedule regular reboots? God no.

Re: Accidentally Load Bearing

#57
post #51
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…

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

I think one of the reasons I've seen this happen is because typically, EE and ME programs in university teach very little CS "enough to be dangerous", and the few coding projects you are required to do are often taught in a way that downplays the importance of the software. Software is often seen as simply a translation or manifestation of a classical mathematical model or control system ( or even directly generated by Matlab/Simulink).

Software, being less familiar, is not viewed as a fundamental architectural component because there often isn't sufficient understanding of the structure or nuance involved in building it. In my experiences software or firmware engineers tend to be isolated from the people who designed the physical systems, and a lot of meaning is lost between the two teams because the software side does not understand the limitations and principles of the hardware and the hardware team does not understand the capabilities and limitations of the software.

Re: Accidentally Load Bearing

#58
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 to fix a [Electrical/Mechanical] problem, a Gremlin is born". I think I get the gist, but that sentence is missing some words.

oooboy is it. That's what I get for not proofreading.

Re: Accidentally Load Bearing

#59
post #21

Earlier quoted context omitted.

It is Hyrums law. The observable feature of the board was that it could bear load despite that not being the intention, and the house started using this observable feature.

>> Hyrum’s law > It is Hyrums law. No, it's "Hyrum's" not "Hyrums": https://www.hyrumslaw.com/

Is this an instance of Cole's law: The fastest way to get the right answer is to post the wrong answer?

Re: Accidentally Load Bearing

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

On the other hand there was Juicero...

I don't follow. Did you accidentally reply to the wrong comment?
Post reply on HN