Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

I love that article, but it made me sad. It is just as relevant today, as it was, nine years ago.

I'm a huge proponent of improving software Quality. I have found that complaining about it doesn't actually do much good. My complaints tend to get downvoted into the Mantle, and I just get pissed off.

So, my approach, is to do the very best I can, in my own work, and limit the amount of other people's work on which I rely. When I do use it, I am quite careful, and vet the work. Even so, I have had to back out several highly-rated packages that I had thought were good, but my apps started crashing, as soon as I incorporated them.

Just mentioning that, has often proved incredibly unpopular. It seems to be considered blasphemy.

It does reduce the scope of what I can accomplish, but I am quite happy with what I do.

View on HN

Re:

> I have found that complaining about it doesn't actually do much good. My complaints tend to get downvoted into the Mantle, and I just get pissed off.

IMO creating real change in an organization is almost never done through complaining, it’s done through pushing practical solutions in a positive/constructive way. It might not be the content of your argument, but the way you present it. This comment, for example, instantly biased me against your argument, because the tone felt complain-y and self-righteous. I think regardless of what your argument is, if you present it with this tone, you won’t be persuasive.

Oh, I wasn't talking about in my organization (which was actually famous for Quality). I was talking about making posts in tech communities, like this one.

Software Quality is not a popular topic for discussion. HN isn't too bad, but some other communities react to Quality discussions, as if I was insulting God.

I've learned to just keep my opinions to myself. Even then, when I talk about my own experiences, and my own process, it is not received well.

The problem is, we get less of you and more of them, it damages us all. As long as you keep writing good software though, that's what really matters.

We used to stand in a field where everywhere we looked we could see and hear another of us, now there's 10,000 fools between each of us, and it's rare for us to hear or see another over the crowd.

Well, the issue with discussing Quality, is that it inevitably turns to dependencies, and that's where the "My Precious" stuff starts to happen.

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.

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.

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.

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

Reply on news.ycombinator.com