@Em0nM4stodon I don't know if there is a name for it, but I imagine that for anyone who has been bitten by dependency hell in some form or another, the pendulum has swung in that direction: "I can add library XYZ, and who knows when that is going to bite me, because it's no longer maintained, has a security vulnerability in some unrelated part, etc, or I can write just what I need in 10-50 lines of code.”
@Em0nM4stodon Fffffff, I'd happily suppressed that memory. I'm not responsibly for any Java code directly but we had a few agents on our EC2 instances that turned into moving targets as they stacked almost-fix upon almost-fix that we were pushing as quickly as we reasonably could. 😒
My own experience with dependency hell is more in the realm of Perl, Python, how many versions of jquery we pull in, and groaning at Go source code repos that pull in the kitchen sink and them some more, it seems.
@Em0nM4stodon It’s also called the Not Invented Here Syndrome, causing people to reinvent the wheel rather than use an external dependency.
I definitely have this tendency. On the bright side: I realize by now that other people’s code will never look as bright and shiny as mine simply because it isn’t my code. Unfortunately, this realization doesn’t always stop me from wasting effort. I comfort myself with promises of benefits down the line, which might or might not actually occur.
@Em0nM4stodon Being able to trust the code is one of those benefits that might or might not actually manifest somewhere down the line. It largely depends on your ability to produce code that does what it is supposed to do. 😀
I’ve seen way too many codebases that would have clearly benefited from using an established solution. Way more than got into trouble because of using some third-party library which turned out problematic.
@Em0nM4stodon Case in question: somewhere someone decided that HTTP was so simple, they didn’t need an external dependency for it. So now I am looking at their implementation which parses HTTP responses via substring searches and recognizes exactly the two status codes 400 and 404. Oh, and it isn’t SSL-capable either, which might be the reason they download application updates via plain HTTP. So I’ve got to somehow convince them to throw that thing away and use some decent third-party solution. Preferable by demonstrating a critical buffer overflow, since they also allocate memory in an extremely manual way (no, mere MITM attack likely won’t cut it).
so sorry, I just wanted to comment since I felt like I could contribute something, but I see you've been made aware of embedded programming elsewhere. so sorry, I love your content
@Em0nM4stodon
Not sure if there's a term for what you're describing, but a lot of us old-timers follow this practice.
With the modern dependency hell cough nodejs cough, it can actually be beneficial for maintenance and security.
@Em0nM4stodon
To use an inclusive term I sometimes refer to it as being a craftsperson. Taking that extra time to craft your project or solution with care and discipline.
It also seems to vary by ecosystem. Some favour reusing many small pieces of code, others prefer a more frugal approach to library reuse.
Neither is inherently bad as long as the developer is taking the time to maintain their product.
@Em0nM4stodon
I LOVE to minmax everything. Code with no dependencies, tiny stable ecospheres, tiny houses, demoscene, and so much more. Doing as much as possible with as little as possible is my favorite design constraint!
@Em0nM4stodon I don't think there's a particular job title for this, but it feels like it'd be relatively common in any compliance-heavy industry. Certainly takes a particular kind of person.
@Em0nM4stodon I feel like minimalist programmer might conjure ideas of code golfing instead. While having few dependencies can still mean you have lots of code, even verbose code. Independent programmer? >_>
That's true, and a lot of embedded devices are for automotive, aerospace, and medical equipment that are "safety critical" and using unvetted dependencies is irresponsible. Engineers might only be using CMSIS and a lightweight DO-178C/MISRA-compliant RTOS.
@Em0nM4stodon I'm not widely experienced in developer cultures. In the Perl community where I frequent it's a known approach that isn't frowned upon by everyone (people are mostly respectful of each other styles).
Not sure about other terms, will give it some thought.
Add comment