10 ms·

Accidentally Load Bearing

441 points by jamessun 3y ago

themillerdave 3y ago
I always refer to this as "Load-bearing wallpaper" - in so much that folks who see it, wouldn't think twice about tearing it down - it's wallpaper, right? Well, turns out it was load-bearing wallpaper and the house came down as a result.
oftenwrong 3y ago
The worst part is that it's typically harder to repair the "accidentally load bearing" change than it was to create it in the first place.
dventimihasura 3y ago
> It is extremely probable that we have overlooked some whole aspect of the question https://www.reddit.com/r/ProgrammerHumor/comments/q9x1d2/asking_a_question_on_stack_overflow_and_all_the/ https://www.reddit.com/r/ProgrammerHumor/comments/q9x1d2/ask...
pickledish 3y ago
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 nicer is to work at a place where you don’t expect to make this particular discovery very often, hah
- Qwertious 3y ago
  s/lazy/lack of/ Hidden files in unix were a bug.
  - troupo 3y ago
    And then .DS_Store in MacOS was basically a bug, too. A lack of understanding coupled with a lack of design.
- herpdyderp 3y ago
  > you know when More often than not I've seen this happen because they, in fact, do not know.
- bgribble 3y ago
  > you know when you’re trying to use a decorative stud to hold up part of your house "You" might know it in "your" creations, but in my career I am much more often working and reworking in other people's creations. I think the point of the article is not that you should avoid using decorative studs as load-bearing elements, but that you should be aware that others may have done so before you came along. This is an even more conservative position than the default Chesterton's Fence reading, which is itself dismissed by a lot of people as pedantically restrictive. For me, the parent article resonates. I have definitely had ceilings come crashing down on my head when I removed a piece of "ornamental" trim (programmatically speaking)
  - jerf 3y ago
    "This is an even more conservative position than the default Chesterton's Fence reading, which is itself dismissed by a lot of people as pedantically restrictive." In a normal, real-life context, I can see why someone would feel that way. In a software engineering context I think it's just a further emphasis that you ought to understand what something is doing before fiddling with it, and both the original intent and what it is currently doing are interesting information. Many times I've removed dead code, only to learn that not only was it alive (which wouldn't have been that surprising, it's easy to miss some little thing), but that it is very alive and actually a critical component of the system through some aspect I didn't even know existed, which means I badly screwed up my analysis. The differences between the physical world and the software world greatly amplify the value of the Chesterton's Fence metric. In the physical world we can all use our eyes and clearly see what is going on, and while maybe there's still a hidden reason for the fence that doesn't leap to mind, it's still a 3-dimensional physical problem in the end. Software is so much more interconnected and has so much less regard for physical dimensions that it is much easier to miss relationships at a casual glance. Fortunately if we try, it's actually easier to create a complete understanding of what a given piece of code does, but it is something we have to try at... the "default view" we tend to end up with of software leaves a lot more places for things to hide on us. We must systematically examine the situation with intention. If you don't have time, desire, or ability to do that, the Chesterton's Fence heuristic is more important. We're also more prone to drown under Chesterton's fences if we're not careful, though. I've been in code bases where everyone is terrified to touch everything because it seems like everything depends on everything and the slightest change breaks everything. We have to be careful not to overuse the heuristic too. Software engineering is hard.
- bjornasm 3y ago
  >When making software at least, you know when you’re trying to use a decorative stud to hold up part of your house Do you? Sometimes quick-one-time fixes becomes the center of important software.
- andrewaylett 3y ago
  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.
  - jefftk 3y ago
    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_risk-management_global-chubby-planned-outage https://sre.google/sre-book/service-level-objectives/#xref_r...
    - throwawaymobule 3y ago
      I'm a fan of the 'chaos monkey' (Netflix software) approach of this. Can't expect your platform to be reliable, if it just breaks at random.
- cesaref 3y ago
  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 build for a moving target, and invariably things have changed over time. It's not necessarily a sign of lazy design, it's where the real world intersects with the nice neat pretend world we design for :)
  - convolvatron 3y ago
    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.
    - cesaref 3y ago
      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.
      - convolvatron 3y ago
        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".
- dylan604 3y ago
  >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 Whenever I find myself doing this, I at least leave a comment typically worded along the lines of "the dev is too lazy, not enough time to do it right, or just has no clue what to do, so here you go..."
- dkarl 3y ago
  > in my experience it’s kind of a sign of lazy design Is it always lazy in the bad way, though? In software there's no sharp distinction between "built to carry weight" and "built to tack drywall onto." Whether a system is robust or dangerously unscalable depends on the context. You can always do the thought experiment, "What if our sales team doubled in size and then sold and onboarded customers as fast as they could until we had 100% of the market," and maybe using your database as a message queue is fine for that. If it results in a sad dev team, then that's a case where it was a mistake. It's hard to maintain, or it's an operational nightmare. That isn't the inevitable result of using a (software) decorative stud as a (software) load-bearing element, though. There are a lot of systems happily and invisibly doing jobs they weren't designed for, saving months of work building a "proper" solution.
- im3w1l 3y ago
  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.
hprotagonist 3y ago
reminds me of Hyrum’s law a bit.
- kuchenbecker 3y ago
  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.
  - jefftk 3y ago
    >> Hyrum’s law > It is Hyrums law. No, it's "Hyrum's" not "Hyrums": https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
    - pitaj 3y ago
      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.
      - kuchenbecker 3y ago
        You're correct, I was agreeing and using and example.
      - Dylan16807 3y ago
        It looks like a correction. Confusion here is not being "pedantic".
      - ez667 3y ago
        you misspelled "your"
    - skitter 3y ago
      Is this an instance of Cole's law: The fastest way to get the right answer is to post the wrong answer?
ochoseis 3y ago
One benefit software has over physical systems is that you can easily document it right inside the code with comments and types to make the intention clearer. This isn’t foolproof, especially in dynamic languages like Python, but helps a lot. The analogy for the load bearing stud might be a hackathon project that never expected to see production. In reality, a lot of what we do is hack on something until it barely works, and move on to the next thing.
- eschneider 3y ago
  That's easy to do, if it's _intentional_. I'm always amazed at how often I see systems rate limited by some seemingly "decorative" upstream component, that when removed, causes everything else to run amok. :/
- MilStdJunkie 3y ago
  Yuuuuuup. This precise set of problems is why Systems Engineering was adopted in Aerospace and Defense, because maintenance plans need to know what the "loads" are for each replaceable (spareable) unit or assembly. Today's SE has wandered far, far afield from original goals, tragically enough, but that was the original conception. One of the reasons for today's relatively toothless SE departments is the rise of finance into maintenance planning. Inventory depreciation is a cruel mistress, and "what gets spared" is rarely a SE judgement these days, at least in my experience. This has predictable results, but is partially offset by the exceptionally high bar for aerospace maintenance staff, who are generally pretty damn badass compared to, say, a washing machine repairman. Finance, naturally, would like to knock that bar down a few pegs, too.
mcv 3y ago
I've definitely had this happen. With my own code, even. I build something complex, it's released to production, and a few months later I realise that something about it should be done in a different way, so I look at it, and other people have already built on top of the thing I wanted to change. On the other hand, if you can't figure out what something is for, sometimes the easiest way to find out is to remove it and see what breaks. Maybe that's not such a great idea for that load-bearing stud, but in software it's easy to undo.
binarymax 3y ago
I feel like part of the story is missing. Did he remove the stud and learn the hard way?
- deleted 3y ago
  [deleted]
- jefftk 3y ago
  >> How did you find out the closet partition stud was load bearing, in the end ? > I tried to cut it and it started to bind the saw. I stopped and thought, and then did not cut anymore until I had shored up the upstairs. https://www.jefftk.com/p/accidentally-load-bearing#fb-2312194888989383 https://www.jefftk.com/p/accidentally-load-bearing#fb-231219...
  - h2odragon 3y ago
    A smack with a hammer can tell you all sorts of things. If the board is rotten; some is likely to come off. If it's under tension it'll sing out with a resonance absent from a board carrying only its own weight. In your circumstance, the board should have had some wiggle but prolly wouldn't have.
  - Ensorceled 3y ago
    >> I tried to cut it and it started to bind the saw. I stopped and thought, and then did not cut anymore until I had shored up the upstairs. This is exactly I found out that a stud was now load bearing.
geocrasher 3y ago
This reminds me of end users who unknowingly exploit a bug in a piece of software and integrate it into their normal workflow. The result is that when the bug is fixed, their workflow is interrupted, causing complaints.
- gerad 3y ago
  https://xkcd.com/1172/ https://xkcd.com/1172/
  - Karellen 3y ago
    More formally: > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
- deleted 3y ago
  [deleted]
OldGuyInTheClub 3y ago
Also the denouement to the Fawlty Towers "Builders" episode. https://www.youtube.com/watch?v=jfBOIbjbLv0 https://www.youtube.com/watch?v=jfBOIbjbLv0 (or, jump to https://youtu.be/jfBOIbjbLv0?t=1560 https://youtu.be/jfBOIbjbLv0?t=1560)
dudeinjapan 3y ago
I’m a believer in making a “Single Responsibility: ___” comment at the top of each class.
- marcosdumay 3y ago
  If your class name doesn't answer it, that comment won't either.
irisgrunn 3y ago
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. For example at the end of the roof the tiles weren't wide enough and instead of buying extra roofing tiles, they decided to fill it with cement and pieces of ceramic flower pots.
- dmbche 3y ago
  Degrees away from load bearing paint!
  - hef19898 3y ago
    Or a poster!
- bcrosby95 3y ago
  I had a house that had really bad termite damage and the contractor called it "structural stucco".
  - hinkley 3y ago
    PSA: houses don't 'get termites'. They get water damage, and then the water damage gets termites. Most problems with houses come back to managing water, air, or some other infiltration. But mostly it's water.
    - jwrallie 3y ago
      Maybe in general, but there are particular species of termites (drywood termites) that can derive their water from the wood they consume.
- UncleEntity 3y ago
  Yep, sounds like my garage. At first look it seem like someone backed into the garage door and mangled the hell out of it but on more careful inspection the roof is being barely held up by the tracks that the door runs in and is pretty near to giving up the ghost. Was just going to splice the ends of the rafters (like someone did on the other side who knows how many years ago...if it works, it works) and replace the garage door but now its looking like I'll need a whole new roof. What really worries me is the dodgy wiring strung all across the basement which is a combination of newish wires, old cloth covered wires and liberal applications of electrical tape to splice it all together. Luckily none of the wires seem to be load bearing...
TheCapn 3y ago
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 of programmed limitation, the client wants removed. I always refuse until I can find out why that code exists. Nobody puts code in there for no reason, so I need to know why we have a timer, or an override in the first place. Often the answer is the problem it was solving no longer exists, and that's excellent, but for all the times where that code was put there to prevent something from happening and the client had a bunch of staff turnover, the original purpose is lost. Without documentation telling me why it was done that way I'm very cautious to immediately undo someone else's work. I suppose the other aspect is knowing that I trust my coworkers. They don't (typically) do something for no good reason. If it is in there, it is there for a purpose and I must trust my coworkers to have done their due diligence in the first place. If that trust breaks down then everything becomes more difficult to make decisions on.
- letitbeirie 3y ago
  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.
  - mauvehaus 3y ago
    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://en.wikipedia.org/wiki/Ladder_logic https://en.wikipedia.org/wiki/Ladder_logic
    - 3y ago
csours 3y ago
See also "Swiss Cheese Accident Model" and Melted Cheese Accident Model. Also see also Stockton Rush's statements on safety. He said that most accidents are caused by operator error, so making the sub strong enough wouldn't affect safety.
- marcosdumay 3y ago
  What is that molten cheese accident model? Are you trying to describe deviance normalization?
  - csours 3y ago
    Molten cheese means that something that was intended to increase safety became a hazard during an incident. Think of how the SCRAM at Pripyat/Chernobyl caused the reactor to go supercritical because of the graphite tips. The control rods should have reduced reactivity in the reactor, but the first section of the rod increased reactivity. Or how a hard hat dropped from a height may cause injury.
rkagerer 3y ago
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't keep those current isn't a completed fix. When I come in on a consulting basis I often have to help developers unwind the unintended effects of years of patches before we can safely make seemingly-simple changes. It's analysis-intensive, 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. In some cases where a set of functions is super critical we've made it part of the culture every time altered code is checked in to perform a walkthrough analysis to uncover any fresh unintended side-effects, ensure adherence to design requirements and discover and spotlight non-obvious relationships. The key is to turn the unintended or non-obvious into explicit. Sounds painful but in practice due to the high risk attached to getting that portion of code wrong the developers actually love that time for this is worked into the project schedules - it helps them build confidence the alteration is correct and safe. I wish it were easier to impress the importance of this on inexperienced developers without them having to go through the hell of maintaining code in an environment where it was lacking. It's a skill and art to keep the appropriate level of conciseness to avoid the documentation (no matter which form it takes) becoming too verbose or unwieldy to be helpful.
- latchkey 3y ago
  document the why, not the what. this is also why tests are so important. if you want to remove something, you have to think twice... once for the original code and once to fix the broken tests.
  - regularfry 3y ago
    That has saved me more times than I care to count. "Oh, that's why that code was there. I see."
- Izkata 3y ago
dmbche 3y ago
The term load bearing always bring to my mind the breakdown of how the towers failed during 911 - especially how the plane cutting a lot of vertical steel beams redistributed the weight of the building onto other beams that were not rated to hold most of the buildings weight (while being heated) - they buckle and fail. Guess I'm thinking of being very aware of how the structure reacts to failure, and not necessarily the strenght of all individual parts.
cratermoon 3y ago
This could be considered a variant of Hyrum's Law: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody". At some point the stud was became a structural member, because other changes made it so. Now the second floor depends on it, and removing it would compromise the structural integrity of the second floor.
dclowd9901 3y ago
This is precisely the reason so many developers have come to love functional programming and side-effect-free designs. If that stud _can't_ affect anything outside of its original intended purpose, it can more easily be understood for its purpose and maintained or removed more easily.
wellpast 3y ago
What I've learned from decades of software development: ANY and every component or capability you build into your system, incidentally or explicitly, will immediately (ie tomorrow) become "Accidentally Load Bearing". Dependencies flow in and onto new components like water. This is a fundamental law. Even secret interfaces, etc that you think no one could find or touch will be found and fondled and depended upon. This is why the correct view is that all software is a liability and we should write as little of it as possible, just the minimal that is needed to get the dollars and nothing more.
hinkley 3y ago
I’ve been using, “that was a load bearing poster” for years. Usually right after a P1 and right before an RCA.
Simon_O_Rourke 3y ago
Good Gawd! A stud holding up a second floor by itself... time to have that domicile condemned and the inhabitants moved out asap!
- Cerium 3y ago
  The only option is to do a complete rebuild. The load bearing stud indicates that the foundation design was inadequate for current needs.
- jefftk 3y ago
  The closet partition stud was bearing enough load to matter, but it wasn't holding up the whole second floor by itself. I put in a new beam to replace the load bearing wall the preivous-previous owners had removed, with posts down to the basement: https://www.jefftk.com/p/bathroom-construction-framing https://www.jefftk.com/p/bathroom-construction-framing
7402 3y ago
I used to work with a physics postdoc who would sometime leave a sign on an equipment setup that read, "Do not touch. There are hidden dangers." The lab was full of smart people who were used to looking at things and making their own well-reasoned conclusions about whether it was OK to change something. This was a warning not to be too hasty about doing that!
w10-1 3y ago
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, there's no need for software archeology, the grizzled old veteran who knows every crack, the new wunderkind who can model complex systems in her brain, the comprehensive requirements documentation, or the tentative deploy systems that force user sub-populations to act as lab rats. Indeed, with good tests, I could randomly change the system and stop when I get improvements (exactly how Google reports AI "developed" improvements to sorting). And yet, test developers are paid half or less, test departments are relatively small, QA is put on a fixed and limited schedule, and no tech hero ever rose up through QA. Because it's derivative and reactive?
- mucle6 3y ago
  Chesterton's Test
- jefftk 3y ago
  > 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.
  - conor- 3y ago
    > Except when the tests verify what the code was designed to do, but other systems have grown dependencies on what the code actually does. Assuming you mean systems in terms of actually separate systems communicating via some type of messaging, isn't that where strong enforcement of a contract comes into play so that downstream doesn't have to care about what the code actually does as long as it produces a correct message? > 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. I think this supports GPs point about tests being second-class and not receiving the same level of upkeep or care that the application code receives and one can argue that you should try to prevent being in a position where tests become so brittle you end up with transient dependencies on behavior that was not clear.
avgcorrection 3y ago
HN has such love for that early 20th century writer. So many seemed to have discovered The Fence at about the same time.
deleted 3y ago
[deleted]
ajuc 3y ago
This is why comments in the code aren't that useful, and why commit messages are essential.
orbital-decay 3y ago
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.
lambda 3y ago
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!
squokko 3y ago
I've seen this SO many times. "We'll spin up this server that renders thumbnails of images for the UI."... months pass... "Hey why don't we use the thumbnail server to create low-res images for our marketing emails".... months pass... "The UI doesn't show thumbnails anymore so we can tear out the thumbnail server"
gumby 3y ago
Evolution does this all the time, which is one of the myriad reasons biology is so hard. Really good, brief post.
JohnMakin 3y ago
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 monitoring tools, good rollback plans and procedures/automation should eliminate this fear entirely. If I was afraid to touch anything for fear of breaking it, I'd likely never get anything done.
- ninkendo 3y ago
  > 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!
  - JohnMakin 3y ago
    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.
orobus 3y ago
[dead]
dventimihasura 3y ago
> 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 it deliberately became load bearing, for reasons which are ill conceived to you but not to the people who had them.
- lmm 3y ago
  > 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.
  - dventimihasura 3y ago
    "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.
    - lmm 3y ago
      No, why it was there is a question for whoever put it there, and only them. You might ask other people why they didn't remove it, but that's a different question from why it was there.
      - dventimihasura 3y ago
        Whoever put it there isn't answering any questions, and neither are the people who made it load-bearing later, if they're not alive anymore. No, the question is for you. If you owned this property, would you want to know about the work done by the people who came later and made it load-bearing, or would you rather remain unaware as you go about your renovations?
hinkley 3y ago
> Figuring out something's designed purpose can be helpful in evaluating changes, but a risk is that it puts you in a frame of mind where what matters is the role the original builders intended. One of the biggest challenges I find in refactoring/rearchitecting is getting people to separate why something was done from whether it still needs to exist. Too many times someone has insisted that a weird piece of code needs to exist because we never would have shipped without it. They treat every piece of the structure as intrinsic, and can't conceive of any part of it being scaffolding, which can now be removed to replace with something more elegant and just as functional. When you put a doorway through a loadbearing wall, contractors and smart people place a temporary jack to brace the wall until a lintel can be substituted for the missing vertical members. Some developers behave as if the jack is now a permanent fixture, and I have many theories why but don't know which ones are the real reasons.
praptak 3y ago
Let the system go long enough and everything becomes accidentally load bearing. See also "implementation becomes the specification" - people will come to rely on every single undocumented implementation detail regardless of what the official spec says. That's why it is a good practice to have DiRT or similar exercises. Break things on purpose so that people don't rely on them when they shouldn't.
joshka 3y ago
> 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 <chat tool of choice>, 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.
Waterluvian 3y ago
On the topic of load bearing studs. Is there some way to test for that? How to tell non-destructively how much compression one is under?
duck 3y ago
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".
iancmceachern 3y ago
In mechanical engineering we call this the load path. You want to be sure 1- you know the load path 2- the load path doesn't go where you don't want it to and 3- everything in the load path is strong enough. A good example of a famous failure if this: https://en.m.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse https://en.m.wikipedia.org/wiki/Hyatt_Regency_walkway_collap...
nighthawk454 3y ago
Right, so the trick is not to fall into the false-dichotomy trap. Chesterson's Fence tells if you if you don't understand it's purpose, it's probably not safe to remove. That does not imply that if you do understand it's purpose you can now do whatever you want. Chesterson's Fence doesn't tell you anything about when it's safe to remove, only one category of situations where it probably isn't. But that could be an easy misconception.
wduquette 3y ago
I think the article interprets Chesterton's Fence too strictly. Chesterton's point was simply that you shouldn't destroy something before making sure that it no longer serves any purpose. The fence was simply an illustration. Or, to put it another way, figure out what the consequences are before you decide whether you're willing to intend them or not.

441 points by jamessun 3y ago

I always refer to this as "Load-bearing wallpaper" - in so much that folks who see it, wouldn't think twice about tearing it down - it's wallpaper, right? Well, turns out it was load-bearing wallpaper and the house came down as a result.

oftenwrong 3y ago

The worst part is that it's typically harder to repair the "accidentally load bearing" change than it was to create it in the first place.

dventimihasura 3y ago

> It is extremely probable that we have overlooked some whole aspect of the question https://www.reddit.com/r/ProgrammerHumor/comments/q9x1d2/asking_a_question_on_stack_overflow_and_all_the/ https://www.reddit.com/r/ProgrammerHumor/comments/q9x1d2/ask...

pickledish 3y ago

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 nicer is to work at a place where you don’t expect to make this particular discovery very often, hah

Qwertious 3y ago
s/lazy/lack of/ Hidden files in unix were a bug.
- troupo 3y ago
  And then .DS_Store in MacOS was basically a bug, too. A lack of understanding coupled with a lack of design.
herpdyderp 3y ago
> you know when More often than not I've seen this happen because they, in fact, do not know.
bgribble 3y ago
> you know when you’re trying to use a decorative stud to hold up part of your house "You" might know it in "your" creations, but in my career I am much more often working and reworking in other people's creations. I think the point of the article is not that you should avoid using decorative studs as load-bearing elements, but that you should be aware that others may have done so before you came along. This is an even more conservative position than the default Chesterton's Fence reading, which is itself dismissed by a lot of people as pedantically restrictive. For me, the parent article resonates. I have definitely had ceilings come crashing down on my head when I removed a piece of "ornamental" trim (programmatically speaking)
- jerf 3y ago
  "This is an even more conservative position than the default Chesterton's Fence reading, which is itself dismissed by a lot of people as pedantically restrictive." In a normal, real-life context, I can see why someone would feel that way. In a software engineering context I think it's just a further emphasis that you ought to understand what something is doing before fiddling with it, and both the original intent and what it is currently doing are interesting information. Many times I've removed dead code, only to learn that not only was it alive (which wouldn't have been that surprising, it's easy to miss some little thing), but that it is very alive and actually a critical component of the system through some aspect I didn't even know existed, which means I badly screwed up my analysis. The differences between the physical world and the software world greatly amplify the value of the Chesterton's Fence metric. In the physical world we can all use our eyes and clearly see what is going on, and while maybe there's still a hidden reason for the fence that doesn't leap to mind, it's still a 3-dimensional physical problem in the end. Software is so much more interconnected and has so much less regard for physical dimensions that it is much easier to miss relationships at a casual glance. Fortunately if we try, it's actually easier to create a complete understanding of what a given piece of code does, but it is something we have to try at... the "default view" we tend to end up with of software leaves a lot more places for things to hide on us. We must systematically examine the situation with intention. If you don't have time, desire, or ability to do that, the Chesterton's Fence heuristic is more important. We're also more prone to drown under Chesterton's fences if we're not careful, though. I've been in code bases where everyone is terrified to touch everything because it seems like everything depends on everything and the slightest change breaks everything. We have to be careful not to overuse the heuristic too. Software engineering is hard.
bjornasm 3y ago
>When making software at least, you know when you’re trying to use a decorative stud to hold up part of your house Do you? Sometimes quick-one-time fixes becomes the center of important software.
andrewaylett 3y ago
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.
- jefftk 3y ago
  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_risk-management_global-chubby-planned-outage https://sre.google/sre-book/service-level-objectives/#xref_r...
  - throwawaymobule 3y ago
    I'm a fan of the 'chaos monkey' (Netflix software) approach of this. Can't expect your platform to be reliable, if it just breaks at random.
cesaref 3y ago
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 build for a moving target, and invariably things have changed over time. It's not necessarily a sign of lazy design, it's where the real world intersects with the nice neat pretend world we design for :)
- convolvatron 3y ago
  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.
  - cesaref 3y ago
    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.
    - convolvatron 3y ago
      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".
dylan604 3y ago
>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 Whenever I find myself doing this, I at least leave a comment typically worded along the lines of "the dev is too lazy, not enough time to do it right, or just has no clue what to do, so here you go..."
dkarl 3y ago
> in my experience it’s kind of a sign of lazy design Is it always lazy in the bad way, though? In software there's no sharp distinction between "built to carry weight" and "built to tack drywall onto." Whether a system is robust or dangerously unscalable depends on the context. You can always do the thought experiment, "What if our sales team doubled in size and then sold and onboarded customers as fast as they could until we had 100% of the market," and maybe using your database as a message queue is fine for that. If it results in a sad dev team, then that's a case where it was a mistake. It's hard to maintain, or it's an operational nightmare. That isn't the inevitable result of using a (software) decorative stud as a (software) load-bearing element, though. There are a lot of systems happily and invisibly doing jobs they weren't designed for, saving months of work building a "proper" solution.
im3w1l 3y ago
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.

hprotagonist 3y ago

reminds me of Hyrum’s law a bit.

kuchenbecker 3y ago
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.
- jefftk 3y ago
  >> Hyrum’s law > It is Hyrums law. No, it's "Hyrum's" not "Hyrums": https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
  - pitaj 3y ago
    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.
    - kuchenbecker 3y ago
      You're correct, I was agreeing and using and example.
    - Dylan16807 3y ago
      It looks like a correction. Confusion here is not being "pedantic".
    - ez667 3y ago
      you misspelled "your"
  - skitter 3y ago
    Is this an instance of Cole's law: The fastest way to get the right answer is to post the wrong answer?

ochoseis 3y ago

One benefit software has over physical systems is that you can easily document it right inside the code with comments and types to make the intention clearer. This isn’t foolproof, especially in dynamic languages like Python, but helps a lot. The analogy for the load bearing stud might be a hackathon project that never expected to see production. In reality, a lot of what we do is hack on something until it barely works, and move on to the next thing.

eschneider 3y ago
That's easy to do, if it's _intentional_. I'm always amazed at how often I see systems rate limited by some seemingly "decorative" upstream component, that when removed, causes everything else to run amok. :/
MilStdJunkie 3y ago
Yuuuuuup. This precise set of problems is why Systems Engineering was adopted in Aerospace and Defense, because maintenance plans need to know what the "loads" are for each replaceable (spareable) unit or assembly. Today's SE has wandered far, far afield from original goals, tragically enough, but that was the original conception. One of the reasons for today's relatively toothless SE departments is the rise of finance into maintenance planning. Inventory depreciation is a cruel mistress, and "what gets spared" is rarely a SE judgement these days, at least in my experience. This has predictable results, but is partially offset by the exceptionally high bar for aerospace maintenance staff, who are generally pretty damn badass compared to, say, a washing machine repairman. Finance, naturally, would like to knock that bar down a few pegs, too.

mcv 3y ago

I've definitely had this happen. With my own code, even. I build something complex, it's released to production, and a few months later I realise that something about it should be done in a different way, so I look at it, and other people have already built on top of the thing I wanted to change. On the other hand, if you can't figure out what something is for, sometimes the easiest way to find out is to remove it and see what breaks. Maybe that's not such a great idea for that load-bearing stud, but in software it's easy to undo.

binarymax 3y ago

I feel like part of the story is missing. Did he remove the stud and learn the hard way?

deleted 3y ago
[deleted]
jefftk 3y ago
>> How did you find out the closet partition stud was load bearing, in the end ? > I tried to cut it and it started to bind the saw. I stopped and thought, and then did not cut anymore until I had shored up the upstairs. https://www.jefftk.com/p/accidentally-load-bearing#fb-2312194888989383 https://www.jefftk.com/p/accidentally-load-bearing#fb-231219...
- h2odragon 3y ago
  A smack with a hammer can tell you all sorts of things. If the board is rotten; some is likely to come off. If it's under tension it'll sing out with a resonance absent from a board carrying only its own weight. In your circumstance, the board should have had some wiggle but prolly wouldn't have.
- Ensorceled 3y ago
  >> I tried to cut it and it started to bind the saw. I stopped and thought, and then did not cut anymore until I had shored up the upstairs. This is exactly I found out that a stud was now load bearing.

geocrasher 3y ago

This reminds me of end users who unknowingly exploit a bug in a piece of software and integrate it into their normal workflow. The result is that when the bug is fixed, their workflow is interrupted, causing complaints.

gerad 3y ago
https://xkcd.com/1172/ https://xkcd.com/1172/
- Karellen 3y ago
  More formally: > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
deleted 3y ago
[deleted]

OldGuyInTheClub 3y ago

Also the denouement to the Fawlty Towers "Builders" episode. https://www.youtube.com/watch?v=jfBOIbjbLv0 https://www.youtube.com/watch?v=jfBOIbjbLv0 (or, jump to https://youtu.be/jfBOIbjbLv0?t=1560 https://youtu.be/jfBOIbjbLv0?t=1560)

dudeinjapan 3y ago

I’m a believer in making a “Single Responsibility: ___” comment at the top of each class.

marcosdumay 3y ago
If your class name doesn't answer it, that comment won't either.

irisgrunn 3y ago

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. For example at the end of the roof the tiles weren't wide enough and instead of buying extra roofing tiles, they decided to fill it with cement and pieces of ceramic flower pots.

dmbche 3y ago
Degrees away from load bearing paint!
- hef19898 3y ago
  Or a poster!
bcrosby95 3y ago
I had a house that had really bad termite damage and the contractor called it "structural stucco".
- hinkley 3y ago
  PSA: houses don't 'get termites'. They get water damage, and then the water damage gets termites. Most problems with houses come back to managing water, air, or some other infiltration. But mostly it's water.
  - jwrallie 3y ago
    Maybe in general, but there are particular species of termites (drywood termites) that can derive their water from the wood they consume.
UncleEntity 3y ago
Yep, sounds like my garage. At first look it seem like someone backed into the garage door and mangled the hell out of it but on more careful inspection the roof is being barely held up by the tracks that the door runs in and is pretty near to giving up the ghost. Was just going to splice the ends of the rafters (like someone did on the other side who knows how many years ago...if it works, it works) and replace the garage door but now its looking like I'll need a whole new roof. What really worries me is the dodgy wiring strung all across the basement which is a combination of newish wires, old cloth covered wires and liberal applications of electrical tape to splice it all together. Luckily none of the wires seem to be load bearing...

TheCapn 3y ago

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 of programmed limitation, the client wants removed. I always refuse until I can find out why that code exists. Nobody puts code in there for no reason, so I need to know why we have a timer, or an override in the first place. Often the answer is the problem it was solving no longer exists, and that's excellent, but for all the times where that code was put there to prevent something from happening and the client had a bunch of staff turnover, the original purpose is lost. Without documentation telling me why it was done that way I'm very cautious to immediately undo someone else's work. I suppose the other aspect is knowing that I trust my coworkers. They don't (typically) do something for no good reason. If it is in there, it is there for a purpose and I must trust my coworkers to have done their due diligence in the first place. If that trust breaks down then everything becomes more difficult to make decisions on.

letitbeirie 3y ago
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.
- mauvehaus 3y ago
  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://en.wikipedia.org/wiki/Ladder_logic https://en.wikipedia.org/wiki/Ladder_logic
  - 3y ago

csours 3y ago

See also "Swiss Cheese Accident Model" and Melted Cheese Accident Model. Also see also Stockton Rush's statements on safety. He said that most accidents are caused by operator error, so making the sub strong enough wouldn't affect safety.

marcosdumay 3y ago
What is that molten cheese accident model? Are you trying to describe deviance normalization?
- csours 3y ago
  Molten cheese means that something that was intended to increase safety became a hazard during an incident. Think of how the SCRAM at Pripyat/Chernobyl caused the reactor to go supercritical because of the graphite tips. The control rods should have reduced reactivity in the reactor, but the first section of the rod increased reactivity. Or how a hard hat dropped from a height may cause injury.

rkagerer 3y ago

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't keep those current isn't a completed fix. When I come in on a consulting basis I often have to help developers unwind the unintended effects of years of patches before we can safely make seemingly-simple changes. It's analysis-intensive, 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. In some cases where a set of functions is super critical we've made it part of the culture every time altered code is checked in to perform a walkthrough analysis to uncover any fresh unintended side-effects, ensure adherence to design requirements and discover and spotlight non-obvious relationships. The key is to turn the unintended or non-obvious into explicit. Sounds painful but in practice due to the high risk attached to getting that portion of code wrong the developers actually love that time for this is worked into the project schedules - it helps them build confidence the alteration is correct and safe. I wish it were easier to impress the importance of this on inexperienced developers without them having to go through the hell of maintaining code in an environment where it was lacking. It's a skill and art to keep the appropriate level of conciseness to avoid the documentation (no matter which form it takes) becoming too verbose or unwieldy to be helpful.

latchkey 3y ago
document the why, not the what. this is also why tests are so important. if you want to remove something, you have to think twice... once for the original code and once to fix the broken tests.
- regularfry 3y ago
  That has saved me more times than I care to count. "Oh, that's why that code was there. I see."
Izkata 3y ago

dmbche 3y ago

The term load bearing always bring to my mind the breakdown of how the towers failed during 911 - especially how the plane cutting a lot of vertical steel beams redistributed the weight of the building onto other beams that were not rated to hold most of the buildings weight (while being heated) - they buckle and fail. Guess I'm thinking of being very aware of how the structure reacts to failure, and not necessarily the strenght of all individual parts.

cratermoon 3y ago

This could be considered a variant of Hyrum's Law: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody". At some point the stud was became a structural member, because other changes made it so. Now the second floor depends on it, and removing it would compromise the structural integrity of the second floor.

dclowd9901 3y ago

This is precisely the reason so many developers have come to love functional programming and side-effect-free designs. If that stud _can't_ affect anything outside of its original intended purpose, it can more easily be understood for its purpose and maintained or removed more easily.

wellpast 3y ago

What I've learned from decades of software development: ANY and every component or capability you build into your system, incidentally or explicitly, will immediately (ie tomorrow) become "Accidentally Load Bearing". Dependencies flow in and onto new components like water. This is a fundamental law. Even secret interfaces, etc that you think no one could find or touch will be found and fondled and depended upon. This is why the correct view is that all software is a liability and we should write as little of it as possible, just the minimal that is needed to get the dollars and nothing more.

hinkley 3y ago

I’ve been using, “that was a load bearing poster” for years. Usually right after a P1 and right before an RCA.

Simon_O_Rourke 3y ago

Good Gawd! A stud holding up a second floor by itself... time to have that domicile condemned and the inhabitants moved out asap!

Cerium 3y ago
The only option is to do a complete rebuild. The load bearing stud indicates that the foundation design was inadequate for current needs.
jefftk 3y ago
The closet partition stud was bearing enough load to matter, but it wasn't holding up the whole second floor by itself. I put in a new beam to replace the load bearing wall the preivous-previous owners had removed, with posts down to the basement: https://www.jefftk.com/p/bathroom-construction-framing https://www.jefftk.com/p/bathroom-construction-framing

7402 3y ago

I used to work with a physics postdoc who would sometime leave a sign on an equipment setup that read, "Do not touch. There are hidden dangers." The lab was full of smart people who were used to looking at things and making their own well-reasoned conclusions about whether it was OK to change something. This was a warning not to be too hasty about doing that!

w10-1 3y ago

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, there's no need for software archeology, the grizzled old veteran who knows every crack, the new wunderkind who can model complex systems in her brain, the comprehensive requirements documentation, or the tentative deploy systems that force user sub-populations to act as lab rats. Indeed, with good tests, I could randomly change the system and stop when I get improvements (exactly how Google reports AI "developed" improvements to sorting). And yet, test developers are paid half or less, test departments are relatively small, QA is put on a fixed and limited schedule, and no tech hero ever rose up through QA. Because it's derivative and reactive?

mucle6 3y ago
Chesterton's Test
jefftk 3y ago
> 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.
- conor- 3y ago
  > Except when the tests verify what the code was designed to do, but other systems have grown dependencies on what the code actually does. Assuming you mean systems in terms of actually separate systems communicating via some type of messaging, isn't that where strong enforcement of a contract comes into play so that downstream doesn't have to care about what the code actually does as long as it produces a correct message? > 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. I think this supports GPs point about tests being second-class and not receiving the same level of upkeep or care that the application code receives and one can argue that you should try to prevent being in a position where tests become so brittle you end up with transient dependencies on behavior that was not clear.

avgcorrection 3y ago

HN has such love for that early 20th century writer. So many seemed to have discovered The Fence at about the same time.

deleted 3y ago

[deleted]

ajuc 3y ago

This is why comments in the code aren't that useful, and why commit messages are essential.

orbital-decay 3y ago

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.

lambda 3y ago

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!

squokko 3y ago

I've seen this SO many times. "We'll spin up this server that renders thumbnails of images for the UI."... months pass... "Hey why don't we use the thumbnail server to create low-res images for our marketing emails".... months pass... "The UI doesn't show thumbnails anymore so we can tear out the thumbnail server"

gumby 3y ago

Evolution does this all the time, which is one of the myriad reasons biology is so hard. Really good, brief post.

JohnMakin 3y ago

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 monitoring tools, good rollback plans and procedures/automation should eliminate this fear entirely. If I was afraid to touch anything for fear of breaking it, I'd likely never get anything done.

ninkendo 3y ago
> 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!
- JohnMakin 3y ago
  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.

orobus 3y ago

[dead]

dventimihasura 3y ago

> 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 it deliberately became load bearing, for reasons which are ill conceived to you but not to the people who had them.

lmm 3y ago
> 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.
- dventimihasura 3y ago
  "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.
  - lmm 3y ago
    No, why it was there is a question for whoever put it there, and only them. You might ask other people why they didn't remove it, but that's a different question from why it was there.
    - dventimihasura 3y ago
      Whoever put it there isn't answering any questions, and neither are the people who made it load-bearing later, if they're not alive anymore. No, the question is for you. If you owned this property, would you want to know about the work done by the people who came later and made it load-bearing, or would you rather remain unaware as you go about your renovations?

hinkley 3y ago

> Figuring out something's designed purpose can be helpful in evaluating changes, but a risk is that it puts you in a frame of mind where what matters is the role the original builders intended. One of the biggest challenges I find in refactoring/rearchitecting is getting people to separate why something was done from whether it still needs to exist. Too many times someone has insisted that a weird piece of code needs to exist because we never would have shipped without it. They treat every piece of the structure as intrinsic, and can't conceive of any part of it being scaffolding, which can now be removed to replace with something more elegant and just as functional. When you put a doorway through a loadbearing wall, contractors and smart people place a temporary jack to brace the wall until a lintel can be substituted for the missing vertical members. Some developers behave as if the jack is now a permanent fixture, and I have many theories why but don't know which ones are the real reasons.

praptak 3y ago

Let the system go long enough and everything becomes accidentally load bearing. See also "implementation becomes the specification" - people will come to rely on every single undocumented implementation detail regardless of what the official spec says. That's why it is a good practice to have DiRT or similar exercises. Break things on purpose so that people don't rely on them when they shouldn't.

joshka 3y ago

> 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 <chat tool of choice>, 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.

Waterluvian 3y ago

On the topic of load bearing studs. Is there some way to test for that? How to tell non-destructively how much compression one is under?

duck 3y ago

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

iancmceachern 3y ago

In mechanical engineering we call this the load path. You want to be sure 1- you know the load path 2- the load path doesn't go where you don't want it to and 3- everything in the load path is strong enough. A good example of a famous failure if this: https://en.m.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse https://en.m.wikipedia.org/wiki/Hyatt_Regency_walkway_collap...

nighthawk454 3y ago

Right, so the trick is not to fall into the false-dichotomy trap. Chesterson's Fence tells if you if you don't understand it's purpose, it's probably not safe to remove. That does not imply that if you do understand it's purpose you can now do whatever you want. Chesterson's Fence doesn't tell you anything about when it's safe to remove, only one category of situations where it probably isn't. But that could be an easy misconception.

wduquette 3y ago

I think the article interprets Chesterton's Fence too strictly. Chesterton's point was simply that you shouldn't destroy something before making sure that it no longer serves any purpose. The fence was simply an illustration. Or, to put it another way, figure out what the consequences are before you decide whether you're willing to intend them or not.