Live data from Hacker News

Accidentally Load Bearing

jefftk.com

101–110 of 204 posts

Re: Accidentally Load Bearing

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

> the lack of testing

Having worked on very long-running projects, testing or well-funded QA doesn’t tend to save you from organizational issues.

What typically seems to happen is tests rot, as tests often seem to have a shelf life. Eventually some subset of the tests start to die - usually because of some combination of dependency issues, API expectations changes, security updates, account and credential expirations, machine endpoint and state updates, and so on - and because the results from the test no longer indicate correctness of the program, and the marginal business value of fixing one individual broken test is typically very low, they often either get shut off entirely, or are “forced to pass” even if they ought to be an error.

Repeat for a decade or two and there quickly start being “the tests we actually trust”, and “the tests we’re too busy to actually fix or clean up.”

Which tests are the good ones and bad ones quickly become tribal knowledge that gets lost with job and role changes, and at some point, the mass of “tests that are lying that they’re working” and “tests we no longer care to figure out if they’re telling the truth that they’re failing” itself becomes accidentally load-bearing.

Re: Accidentally Load Bearing

#102
post #63

Earlier quoted context omitted.

The worst part is there's no particular reason for this -- infusing proper software development best practices into existing EE/ME coursework isn't that hard. It's an instance of the larger pattern in which technical degree programs lag industry requirements by decades, as older faculty ossify at the state of the art circa 2-3 years prior to when they received tenure. IMO one way to help would be to get rid of the en…

I definitely think there are two sides to this. The school I went to had a lot of professors for whom the "ossified 2 years prior to tenure" thing was true for, but I also found them to be helpful for teaching fundamental concepts that didn't change in an effective way. I think one barrier to better engineering programs in universities is that there typically is an onerous set of "accreditation requirements" which pr…

> I think one barrier to better engineering programs in universities is that there typically is an onerous set of "accreditation requirements" which prevents significant modification of the curriculum to adapt to modern needs.

This seems to be rapidly dissolving, at least in California. Several schools including Stanford, Cal Tech, and several of the UCs have dropped ABET accreditation for most of their programs in recent years, with more likely to follow as they come up for renewal.

Re: Accidentally Load Bearing

#103
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"

Re: Accidentally Load Bearing

#104
post #20

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

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

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

Re: Accidentally Load Bearing

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

Re: Accidentally Load Bearing

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

And yet, test developers are paid half or less, test departments are relatively small...

Huh? Your first part seemed to be repeating TDD optimism but then you switch test departments. Just make your claims consistent, I'd suggest you instead talk about tests being written by the programmers, kept with the code and automatically run with the build process.

However, I don't think even TDD done right can replace good design and good practices. Notably, even very simple specifications can't be replaced by tests; if f(S) just specified to spit out a string concatenated with itself, there's not obvious test treating f as a black box that verifies that f is correct. Formal specifications matter, etc. You can spot check this but if the situation is one magic wrong value screws you in some way, then your test won't show this.

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.

Wow, sure, all that stuff can be parodied but it's all a response to software being hard. And software is hard, sorry.

Re: Accidentally Load Bearing

#109

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

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

Post reply on HN