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.
Accidentally Load Bearing
61–70 of 204 posts
Re: Accidentally Load Bearing
#62Part 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'…
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.
Re: Accidentally Load Bearing
#63Earlier quoted context omitted.
> 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 to fix a [Electrical/Mechanical] problem, a Gremlin is born". At least some of this is cultural. EEs and MEs have historically viewed software less seriously than…
I think one of the reasons I've seen this happen is because typically, EE and ME programs in university teach very little CS "enough to be dangerous", and the few coding projects you are required to do are often taught in a way that downplays the importance of the software. Software is often seen as simply a translation or manifestation of a classical mathematical model or control system ( or even directly generated…
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 entire notion of a "Professor".
Instead, courses should be taught primarily by a combination of professional instructors on permanent contracts and teacher-practitioners supported by the instructors. The instructors should have occasional sabbaticals for the professional instructors to embed in firms and ensure they're up to date on the industry.
The research side of the university can even more easily replace Professors and tenure with first-line lab managers on 3-5 year contracts whose job is simply to apply for grants and run labs, and who can teach if they want but are held to the same standards as any other applicant for an ad junct teaching position in any particular term.
Re: Accidentally Load Bearing
#64I had something similar. A couple of years ago I bought on old house. The previous owners did most of the work themselves from the 1960s on. The zinc gutter had leaked for probably decades and it destroyed part of the roof structure. The roof was held up by the wooden paneling the used to cover it on the inside (70s). So the wooden paneling was actually load bearing Actually I've found way more stuff in this house. F…
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...
Re: Accidentally Load Bearing
#65Earlier quoted context omitted.
I think one of the reasons I've seen this happen is because typically, EE and ME programs in university teach very little CS "enough to be dangerous", and the few coding projects you are required to do are often taught in a way that downplays the importance of the software. Software is often seen as simply a translation or manifestation of a classical mathematical model or control system ( or even directly generated…
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 prevents significant modification of the curriculum to adapt to modern needs.
The other barrier is that students culturally appear to not always want to do more coding than needed. Courses involving coding were widely regarded as the most difficult by the people around me, despite something like up to 80% of an EE class going into SW engineering after graduating.
I think in general, degree programs are designed to be something that they're not used for anymore often. The usual line is that they're designed to provide a track to academia, and aren't vocational training. But nowadays degrees seem very ritualistic and ornamental - it seems that people are doing their learning on the job mostly whatever they do, and the relevance of the degree itself is just a shibboleth of some sort.
Re: Accidentally Load Bearing
#66What 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.
Re: Accidentally Load Bearing
#67Earlier quoted context omitted.
> 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. Isn't that just the regular Chesterton's Fence argument though? The one the article is specifically written to point out is not…
All my comment is adding a software anecdote to the story. It really is just regular Chesterton's Fence, a term I've never heard until now but dealt with for the last several years. You're not wrong, but in the context of a PLC controlling a motor or gate it is far more segregated than the code you're probably thinking of. Having a timer override on a single gate's position limit sensor would have no effect on a sepa…
I think they’re thinking of things like that software control for the health machine that could get in a state where it would give a lethal dose to a patient.
Re: Accidentally Load Bearing
#68I’ve been using, “that was a load bearing poster” for years. Usually right after a P1 and right before an RCA.
Re: Accidentally Load Bearing
#69I had something similar. A couple of years ago I bought on old house. The previous owners did most of the work themselves from the 1960s on. The zinc gutter had leaked for probably decades and it destroyed part of the roof structure. The roof was held up by the wooden paneling the used to cover it on the inside (70s). So the wooden paneling was actually load bearing Actually I've found way more stuff in this house. F…
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…
Carefully reading the NEC indicates that loads of electrical tape is permitted way more often than you’d think it should …
Re: Accidentally Load Bearing
#70Huh. 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…
> 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.
I would like to think that if I sent out an email about git hygiene that you would support me against the people who don’t understand why I get grumpy at them for commits that are fifty times as long as the commit message, and mix four concerns two of which aren’t mentioned at all.
Git history is useless until you need it, and then it’s priceless.
I can’t always tell what I meant by a block of code I wrote two years ago, let alone what you meant by one you wrote five years ago.