5 ms·

I agree with the article. There is too much crap today in software. Much of it external crap. When I was young, I used to scoff when old programmers told me no

by _wldu 7y ago

I agree with the article. There is too much crap today in software. Much of it external crap. When I was young, I used to scoff when old programmers told me not to include external/3rd-party libraries. What did they know, these libs are so convenient! Today, I clearly see the downside of doing that and the slippery slope that it introduces. Rather than do the hard work myself upfront and pay that cost, I let someone else do it for me and simply included their work. Great, right? Not really. Now, I'm at their mercy. They break things all the time, don't address security issues, abandon the code I rely on, don't support OpenBSD armv7 (or whatever you run on), etc. Now, I'm much older and only include when there is absolutely no other way (very rarely).

criddell 7y ago
> old programmers told me not to include external/3rd-party libraries That's me. I also avoid plug ins in things like our bug tracker and build system. I'm the person that maintains our Redmine and Jenkins machines and over the years I've gotten lots of requests for plug-ins that do pretty neat things. I almost always refuse just because it makes updating such a pain in the ass. Generally, I do as little custom configuration as I possibly can these days. Twenty-five years ago customizing Enlightenment was how I spent about 30% of my time at the computer.
tasogare 7y ago
I shudder everytime I run npm install on my lab main software project, which downloads hundreds if not thousands of external dependencies and lists more than 400 vulnerabilities. On the reverse when I own a project, dependencies are kept to the minimum, often code I own too.
- collyw 7y ago
  We have a new React front-end for our application. It's fairly simple but the amount of crap installed by npm is incredible. Then trying to fix bugs is a nightmare depending on what needs done. This stuff was supposed to make our lives easier...
bob1029 7y ago
I am the same way with 3rd party libraries. My policy is that I will allow the use of a 3rd party library if it can bring some immediate value without compromising the downstream roadmap of the product. Additionally, any 3rd party library used should be continually evaluated for risk. Keeping an eye on how frequently certain things are maintained, their various roadmaps, etc is quite the chore. But, if you don't do this you are setting yourself up for disaster. At the slightest hint of something looking like it would compromise us in a 3rd party lib, we will take the time to implement it from scratch 100% our way. That said, there is some interesting nuance I am starting to see in various communities. For instance, in .NET land, the Newtonsoft.Json library is extremely popular and was eventually scooped up into the official Microsoft API (and then further enhanced performance-wise). As a result, we had a clean migration path from a 3rd party library to the 1st party's API implementation of the same functionality. This is the most ideal situation from my perspective, and I would really like to see more of this. Perhaps a new system from various vendors where a 3rd party library author can apply for 1st party sponsorship and/or certification of their library. Since Microsoft owns GitHub now, this could be something they consider integrating directly into the product. GitHub already has quite a few features that could help to support such capabilities (I.e. static code analyzers, action pipelines, etc). Additionally, if you are using a CLR language like C#, exceptionally powerful tools like Roslyn are available. I realize this may create certain perverse incentives, but seeing a "Certified by Microsoft" or similar label affixed to a GitHub repository would give me a substantial boost in confidence when using this author's library. This would also serve as an excellent canary (i.e. if this status is revoked based on malicious activity, too many incidents, lack of maintenance, etc.).

by _wldu 7y ago

criddell 7y ago

> old programmers told me not to include external/3rd-party libraries That's me. I also avoid plug ins in things like our bug tracker and build system. I'm the person that maintains our Redmine and Jenkins machines and over the years I've gotten lots of requests for plug-ins that do pretty neat things. I almost always refuse just because it makes updating such a pain in the ass. Generally, I do as little custom configuration as I possibly can these days. Twenty-five years ago customizing Enlightenment was how I spent about 30% of my time at the computer.

tasogare 7y ago

I shudder everytime I run npm install on my lab main software project, which downloads hundreds if not thousands of external dependencies and lists more than 400 vulnerabilities. On the reverse when I own a project, dependencies are kept to the minimum, often code I own too.

collyw 7y ago
We have a new React front-end for our application. It's fairly simple but the amount of crap installed by npm is incredible. Then trying to fix bugs is a nightmare depending on what needs done. This stuff was supposed to make our lives easier...

bob1029 7y ago

I am the same way with 3rd party libraries. My policy is that I will allow the use of a 3rd party library if it can bring some immediate value without compromising the downstream roadmap of the product. Additionally, any 3rd party library used should be continually evaluated for risk. Keeping an eye on how frequently certain things are maintained, their various roadmaps, etc is quite the chore. But, if you don't do this you are setting yourself up for disaster. At the slightest hint of something looking like it would compromise us in a 3rd party lib, we will take the time to implement it from scratch 100% our way. That said, there is some interesting nuance I am starting to see in various communities. For instance, in .NET land, the Newtonsoft.Json library is extremely popular and was eventually scooped up into the official Microsoft API (and then further enhanced performance-wise). As a result, we had a clean migration path from a 3rd party library to the 1st party's API implementation of the same functionality. This is the most ideal situation from my perspective, and I would really like to see more of this. Perhaps a new system from various vendors where a 3rd party library author can apply for 1st party sponsorship and/or certification of their library. Since Microsoft owns GitHub now, this could be something they consider integrating directly into the product. GitHub already has quite a few features that could help to support such capabilities (I.e. static code analyzers, action pipelines, etc). Additionally, if you are using a CLR language like C#, exceptionally powerful tools like Roslyn are available. I realize this may create certain perverse incentives, but seeing a "Certified by Microsoft" or similar label affixed to a GitHub repository would give me a substantial boost in confidence when using this author's library. This would also serve as an excellent canary (i.e. if this status is revoked based on malicious activity, too many incidents, lack of maintenance, etc.).