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

151–160 of 204 posts

Re: Accidentally Load Bearing

#151

Post by lmm »

dventimihasura wrote: post #111

> I could easily tell why it was there: it was part of a partition for a closet. > Except that over time it had become accidentally load bearing > through other (ill conceived) changes to the structure this stud was now helping hold up the second floor of the house Evidently, you couldn't easily tell why it was there. Moreover, I'm not persuaded that it accidentally became load bearing. It seems quite plausible that…

> Evidently, you couldn't easily tell why it was there.

No, they could tell why it was there. It's just that knowing why it was there in the first place doesn't tell you what it's doing now.

Re: Accidentally Load Bearing

#152

Post by Izkata »

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"

Gizmo caca.

(...I just watched both Gremlins movies last weekend...)

Re: Accidentally Load Bearing

#153

Post by joshka »

> This is a concept I've run into a lot when making changes to complex computer systems. It's useful to look back through the change history, read original design documents, and understand why a component was built the way it was. But you also need to look closely at how the component integrates into the system today, where it can easily have taken on additional roles.

We're probably at a stage where doing this in an automated fashion might be reasonable. The context for why something works a particular way (say in some github repo) is the commit message and change detail, the PR, related issues, related chats in , and then things temporally related to those. Feeding an LLM with the context and generating ADRs for an entire project automatically could be a feasible approach.

Re: Accidentally Load Bearing

#155

Post by Izkata »

rkagerer wrote: post #32

Part of writing and maintaining good code is maintaining useful documentation (such as comments) expressing clear rationale and intent. Simple stuff can be elegantly implicit, and modern languages are getting better at capturing more of this in syntax and eliminating common footguns. But more complex systems tend to benefit from explicit explanation or even external design documents (like diagrams). A fix that doesn'…

> and like an archaeologist any artifacts I can dig up that you've left behind providing clues to what was in your head at the time can be helpful.

This is why I'm against squashing commits in git, that our other development teams don't understand: you're going through extra effort to make it more difficult in the future.

Re: Accidentally Load Bearing

#156

Post by duck »

We remodeled our kitchen several years ago. In the old kitchen there was a large beam running across one end, added during some other remodel before we owned the house to add a second floor, but since we wanted to expand on the kitchen this really needed to go. Upon tearing into the ceiling, it was found this beam was ~2 feet to the right of where it should of been to support the wall above. They fixed it and moved the beam into the wall upstairs and it all worked out, but when I asked about the original location the builder basically said: "you had one person that wanted to do the right thing, and one person that didn't care, and quality always ends up with the lowest setting".

Re: Accidentally Load Bearing

#157

Post by convolvatron »

cesaref wrote: post #143
convolvatron wrote: post #96

Earlier quoted context omitted.

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

hopefully there is some other place to try your code than in production. that gives you the agency to say "lets just take it out and see what happens".

Re: Accidentally Load Bearing

#158

Post by dventimihasura »

lmm wrote: post #151
dventimihasura wrote: post #111

> I could easily tell why it was there: it was part of a partition for a closet. > Except that over time it had become accidentally load bearing > through other (ill conceived) changes to the structure this stud was now helping hold up the second floor of the house Evidently, you couldn't easily tell why it was there. Moreover, I'm not persuaded that it accidentally became load bearing. It seems quite plausible that…

> Evidently, you couldn't easily tell why it was there. No, they could tell why it was there. It's just that knowing why it was there in the first place doesn't tell you what it's doing now.

"Why it was there" is something that matters to people, plural. Knowing why it was for some people doesn't rule out the possibility that you don't know why it was there for other people.

Re: Accidentally Load Bearing

#159

Post by scubbo »

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.

You may enjoy https://brooker.co.za/blog/2020/06/23/code.html

Re: Accidentally Load Bearing

#160

Post by scubbo »

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.

This is a statement which is technically-true (so long as your language of choice has no length on names), but unhelpful since it does not apply in most practical cases.
Post reply on HN