Live data from Hacker News

Accidentally Load Bearing

jefftk.com

91–100 of 204 posts

Re: Accidentally Load Bearing

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

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

Except when the tests verify what the code was designed to do, but other systems have grown dependencies on what the code actually does.

Or when you're removing unused code and its associated tests, but it turns out the code is still used.

Or when your change fails tests, but only because the tests are brittle so you fix the test to match the new situation. Except it turns out something had grown a dependency on the old behavior.

Tests are great, and for sufficiently self contained systems they can be all you need. In larger systems, though, sometimes you also need telemetry and/or staged rollouts.

Re: Accidentally Load Bearing

#94
Related concept from software engineering is "accidentally quadratic", which can manifest itself in the most unexpected places when two unrelated things collide.

Both generalize to various forms of causal and failure analysis in systems design.

Re: Accidentally Load Bearing

#95
post #76

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…

If you go back to the early 1900s, the cladding was installed on a diagonal, which helped greatly in preventing the building from racking. Now we rely on sheet rock and plywood to provide that protection in earthquakes and wind storms. If you ever see a house stripped down to the sticks for a rebuild, you will hopefully notice a few braces added. Not to keep the walls from falling down, but to keep them square and tr…

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

Re: Accidentally Load Bearing

#96
post #18

This (the unimportant stud becoming load bearing later on) makes sense, but in my experience it’s kind of a sign of lazy design. When making software at least, you know when you’re trying to use a decorative stud to hold up part of your house, and choosing to do it anyway instead of building some new better structure does make for a pretty sad dev team later on This is to say —- I agree with the article, but much nic…

Well, let's say you are working on a well engineered and tested product, and you look at the code coverage, and there's a whole lump of functionality that has no coverage. You could conclude that the code is unnecessary and remove it, or you could conclude that some test cases need to be added to exercise it. How do you decide which is correct? The problem is usually that well thought and and designed software was bu…

I'm deeply frustrated at the missing answer here. read the code. figure out what's it for. take out it and see what breaks. software is not a house, you can completely wreck it and set in back exactly the way it was in a second.

there is no excuse for not owning and knowing the software you are supposed to be in control of.

Re: Accidentally Load Bearing

#97
post #50
post #45

Earlier quoted context omitted.

I'll never do PLC work again. Forget undocumented code, most of the time there's no schematics for the hardware you're working on because it was custom-built thirty years ago.

My company is generally good about that. We have lots of overlapping documentation that answers questions like that in different ways. From Electrical schemas to QA docs, picture archives of panels and wiring, ticketing systems, spreadsheets over I/O, etc. etc. I hate PLC work for other reasons. I'm starting to look at going back to more traditional software role. I'm a bit tired of the road work and find the compens…

Ayep. When you're the PLC guy they expect you to know how to fix anything that plugs into a wall but isn't understood by the electricians.

Re: Accidentally Load Bearing

#98

This (the unimportant stud becoming load bearing later on) makes sense, but in my experience it’s kind of a sign of lazy design. When making software at least, you know when you’re trying to use a decorative stud to hold up part of your house, and choosing to do it anyway instead of building some new better structure does make for a pretty sad dev team later on This is to say —- I agree with the article, but much nic…

I've been happily running a service that's non-critical, only to discover when we have an outage (that should be a non-event) that another team has started relying on it for something business critical.

This was famously a problem for Google's distributed lock service, Chubby. They handled it by intentionally having outages to flush out ways it might have started to bear loads it wasn't designed for: https://sre.google/sre-book/service-level-objectives/#xref_r...

Re: Accidentally Load Bearing

#99
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.

but now its like the number of licks to the center of tootsie pop the world may never know!

Re: Accidentally Load Bearing

#100
My favorite "accidentally load bearing" artifact that I've found was a misconfigured sudo that would easily allow arbitrary code execution as root (it allowed passwordless sudo for a find command, which could be used with -exec), which a number of important support scripts for the product had been written to use. Load bearing privilege escalation!
Post reply on HN