4 ms·

A touché, but regardless, I think tone and the way you make your argument matters a lot, vs. just the position you support. I personally see a tonne of people p

by yashap 5y ago

A touché, but regardless, I think tone and the way you make your argument matters a lot, vs. just the position you support. I personally see a tonne of people passionate about software quality on HN, and often their arguments are very well received. If your argument comes off as “I don’t use libraries because everyone else’s software is crap, so I write everything myself,” people aren’t going to respond well to that. But if you can make a convincing argument for why it makes sense to avoid dependencies in specific situations, I’d imagine you’ll get a positive reaction.

ChrisMarshallNY 5y ago
I don't really get too bent out of shape about other folks' code. I've found that it doesn't really help my position to compare against others'. If the only way that I can justify my own worth, is to tear down others, then my own position isn't so good. But I have had issues, when incorporating the work of others. I do use a couple of dependencies, in my work; but just a couple (besides the default ones, like standard libs, and platform SDKs). That's a big reason that I don't use cross-platform frameworks, like QT or React Native. They are fine, but I feel that they reduce the quality of the user experience. I've tried using them for decades (cross-platform frameworks are nothing new), and have never been happy with the result. I am always nervous about running the critical path through dependencies. I worked on a project, a few years ago, that was completely based around a particular tool; assuming the tool would improve, and that our implementation of it would improve, as we learned more. Neither happened. In fact, the more we learned about the tool, the more we realized how unsuitable it was. That ended up being a real disaster. Basically flushed a couple of years (and several million dollars) down the drain. So I tend to stick with native, and I also write my own dependencies. I believe in modular architecture. It does have a few issues, but these can be greatly mitigated, if I have control of the whole stack. I come from an embedded background. I have worked with computers, right down to the FET junctions, and I like to know what's going on, everywhere. I'm uncomfortable relying on stuff I don't understand. I've learned to relax, over the years. Compiler toolchains are really quite good, and I don't understand them (in detail). I don't understand AI/ML, and I'm not quite to the point, where I incorporate them without question, but I think we'll be at that point, fairly soon. I'm kind of amazed that a lot of folks google a dependency, then add it as a critical path component, without a second thought. I guess it has positive results (meaning that money is made) often enough, but I consider that living a bit too dangerously, for my comfort.
- yashap 5y ago
  Yeah, I get the “I like to understand how everything works” angle, and I like implementing things from scratch in personal projects. When working with a team, I feel it really depends on the team and the business. I think if you’re extremely focused on quality, and don’t need a really rapid pace of development (especially in the earlier days), then going low/no dependency can make sense. It’s certainly working for SQLite! On the flip side … some of the worst software mistakes at places I’ve worked at have been of the “let’s build some common thing ourselves” variety. For example, for some crazy reason, someone implemented their own HTTP-esque protocol on top of ZeroMQ, complete with servers and clients in multiple languages, that was used in a massive number of services. A total disaster, insane amounts of dev work invested in it, tonnes of bugs and performance issues, eventually we ripped it out and replaced it with HTTP, but it took literally years of work to do so. Less extreme were in-house service discovery tooling, and an in-house version of something like Redux. Tonnes of investment to build them, poorly documented with poor test coverage and lots of bugs. Then the main author/advocate leaves the company, it becomes a huge maintenance burden, and eventually it’s ripped out and replaced with a popular open source version at great cost/effort. In all cases, the in-house version was massively lower quality than the top open source alternatives, in basically every conceivable way. I agree that introducing a dependency is a significant decision, you should research the dependency well and not add it lightly. But building everything in-house can be a major mistake with massive unnecessary costs, you need pretty specific use cases and the right company culture for it to work out.
  - ChrisMarshallNY 5y ago
    Well, the classic example of “don’t roll your own,” is encryption. But choosing an encryption system is one of the more important decisions a developer makes, as an error can be an “E.L.E,” so to speak. https://m.youtube.com/watch?v=j0silSyYFPM https://m.youtube.com/watch?v=j0silSyYFPM

by yashap 5y ago

ChrisMarshallNY 5y ago

I don't really get too bent out of shape about other folks' code. I've found that it doesn't really help my position to compare against others'. If the only way that I can justify my own worth, is to tear down others, then my own position isn't so good. But I have had issues, when incorporating the work of others. I do use a couple of dependencies, in my work; but just a couple (besides the default ones, like standard libs, and platform SDKs). That's a big reason that I don't use cross-platform frameworks, like QT or React Native. They are fine, but I feel that they reduce the quality of the user experience. I've tried using them for decades (cross-platform frameworks are nothing new), and have never been happy with the result. I am always nervous about running the critical path through dependencies. I worked on a project, a few years ago, that was completely based around a particular tool; assuming the tool would improve, and that our implementation of it would improve, as we learned more. Neither happened. In fact, the more we learned about the tool, the more we realized how unsuitable it was. That ended up being a real disaster. Basically flushed a couple of years (and several million dollars) down the drain. So I tend to stick with native, and I also write my own dependencies. I believe in modular architecture. It does have a few issues, but these can be greatly mitigated, if I have control of the whole stack. I come from an embedded background. I have worked with computers, right down to the FET junctions, and I like to know what's going on, everywhere. I'm uncomfortable relying on stuff I don't understand. I've learned to relax, over the years. Compiler toolchains are really quite good, and I don't understand them (in detail). I don't understand AI/ML, and I'm not quite to the point, where I incorporate them without question, but I think we'll be at that point, fairly soon. I'm kind of amazed that a lot of folks google a dependency, then add it as a critical path component, without a second thought. I guess it has positive results (meaning that money is made) often enough, but I consider that living a bit too dangerously, for my comfort.

yashap 5y ago
Yeah, I get the “I like to understand how everything works” angle, and I like implementing things from scratch in personal projects. When working with a team, I feel it really depends on the team and the business. I think if you’re extremely focused on quality, and don’t need a really rapid pace of development (especially in the earlier days), then going low/no dependency can make sense. It’s certainly working for SQLite! On the flip side … some of the worst software mistakes at places I’ve worked at have been of the “let’s build some common thing ourselves” variety. For example, for some crazy reason, someone implemented their own HTTP-esque protocol on top of ZeroMQ, complete with servers and clients in multiple languages, that was used in a massive number of services. A total disaster, insane amounts of dev work invested in it, tonnes of bugs and performance issues, eventually we ripped it out and replaced it with HTTP, but it took literally years of work to do so. Less extreme were in-house service discovery tooling, and an in-house version of something like Redux. Tonnes of investment to build them, poorly documented with poor test coverage and lots of bugs. Then the main author/advocate leaves the company, it becomes a huge maintenance burden, and eventually it’s ripped out and replaced with a popular open source version at great cost/effort. In all cases, the in-house version was massively lower quality than the top open source alternatives, in basically every conceivable way. I agree that introducing a dependency is a significant decision, you should research the dependency well and not add it lightly. But building everything in-house can be a major mistake with massive unnecessary costs, you need pretty specific use cases and the right company culture for it to work out.
- ChrisMarshallNY 5y ago
  Well, the classic example of “don’t roll your own,” is encryption. But choosing an encryption system is one of the more important decisions a developer makes, as an error can be an “E.L.E,” so to speak. https://m.youtube.com/watch?v=j0silSyYFPM https://m.youtube.com/watch?v=j0silSyYFPM