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

141–150 of 204 posts

Re: Accidentally Load Bearing

#141

Post by im3w1l »

pickledish wrote: post #2

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…

Let's say you code defensively. You add some handling invalid input to your function. Because the rest of your codebase never sends it invalid input it's dead code - not load bearing. Until at some point a bug is introduced and sends you invalid input which is then dutifully handled and recovered from. The branch has become load bearing.

Re: Accidentally Load Bearing

#142

Post by [deleted] »

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.

[deleted]

Re: Accidentally Load Bearing

#143

Post by cesaref »

convolvatron wrote: post #96
cesaref wrote: post #18

Earlier quoted context omitted.

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.

Well, if it isn't covered, then you can take it out, and see what breaks (nothing) and then discover in production why it was there :)

But yes, it's basically what the job comes down to - having a strategy for managing complexity in all it's forms, and this is a fine example of the sort of problem that you don't learn in college.

I've (thankfully) never deprecated code and caused serious production issues, but i've seen it happen. The best places to work expect this sort of issue, and have process in place to roll back and deal with it, like any other business continuity issue (e.g. power/network loss).

The moment you find yourself scared of changing code because you don't understand the consequences then you've basically lost the battle.

Re: Accidentally Load Bearing

#144

Post by hinkley »

jefftk wrote: post #133
hinkley wrote: post #128

Earlier quoted context omitted.

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.

Laying a board over a seam in the subfloor sounds like a titanic pain in the ass. Diagonal means you might have to move the nail a little. Probably also limits the amount of dust and water that passes through from floor to ceiling.

Re: Accidentally Load Bearing

#145

Post by mike_hock »

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…

The last part is also useful. Tells the next person where to look when they do run into scaling issues, and also tells them that there wasn't some other reason to do it.

Re: Accidentally Load Bearing

#146

Post by ninkendo »

JohnMakin wrote: post #107

I have seen too often overly complicated systems where one small change creates these situations that go unnoticed for far too long and then something breaks in a mystifying and spectacular way. The reaction, generally, is then a fear to make any change to the system at all, regardless of how benign, even if it can't possibly mess something up - because of fear of the "unknown." IME, having robust alerting and monito…

> having robust alerting and monitoring tools, good rollback plans and procedures/automation should eliminate this fear entirely.

Sure, but that all sounds like stuff that happens after you deploy/release… you really need to catch things sooner than that. Don’t make the user into the one who has to find the breakage, please. No matter how fast you roll back. Test your software thoroughly!

Re: Accidentally Load Bearing

#147

Post by JohnMakin »

ninkendo wrote: post #146
JohnMakin wrote: post #107

I have seen too often overly complicated systems where one small change creates these situations that go unnoticed for far too long and then something breaks in a mystifying and spectacular way. The reaction, generally, is then a fear to make any change to the system at all, regardless of how benign, even if it can't possibly mess something up - because of fear of the "unknown." IME, having robust alerting and monito…

> having robust alerting and monitoring tools, good rollback plans and procedures/automation should eliminate this fear entirely. Sure, but that all sounds like stuff that happens after you deploy/release… you really need to catch things sooner than that. Don’t make the user into the one who has to find the breakage, please. No matter how fast you roll back. Test your software thoroughly!

Nothing I said implies the user has to find it. With rolling deployments and blue/green strategies, bad changes don't even have the potential to go live.

Re: Accidentally Load Bearing

#148

Post by ndiddy »

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.

The Juicero was terrible hardware in the sense that they could have made a product that was functionally similar but cost far less to make. It seems like they got a hardware engineering team straight out of college and gave them no constraints or budget. You have a giant CNC'd aluminum frame, a custom gearbox, a custom power supply, a custom drive motor, etc. All of this is only necessary because they decided to squeeze the juice out of the bags by applying thousands of pounds of force to the entire surface of the bag at once vs. using a roller or something. They were likely losing hundreds of dollars per unit even when they were selling the press for $600.

Re: Accidentally Load Bearing

#149

Post by derefr »

MrBuddyCasino wrote: post #83
bamfly wrote: post #46

Earlier quoted context omitted.

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…

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.

“Why” isn’t a property of the code itself, though; it’s rather a property of the process of creating the code.

Because of this, my personal belief is that the justification for any line of code belongs in the SCM commit message that introduced the code. `git blame` should ultimately take you to a clear, stand-alone explanation of “why” — one that, as a bonus, can be much longer than would be tolerated inline in the code itself.

Of course, I’m probably pretty unusual, in that I frequently write paragraphs of commit message for single-line changes if they’re sufficiently non-obvious; and I also believe that the best way to get to know a codebase isn’t to look at it in its current gestalt form, but rather to read its commit history forward from the beginning. (And that if other programmers also did that, maybe we’d all write better commit messages, for our collective future selves.)

Re: Accidentally Load Bearing

#150

Post by pitaj »

jefftk wrote: post #21
kuchenbecker wrote: post #13

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/

Not sure if this is a joke or if you're actually that pedantic to think they purposefully left off the apostrophe because they think it's called "Hyrums law" not "Hyrum's law".

They were agreeing with the top-level comment, not correcting their spelling.

Post reply on HN