Hacker News Reader

Comment by rhn_mk1 | Hacker News Reader

There is a sweet spot somewhere between the extreme of not using pre-built tools and drowning in them.

I've been following a similar path: automation and testing give me certainty and peace of mind when I'm working on bigger teams, so they should also improve my personal projects, right?

Well, the difference is that my personal projects are used only by me in limited ways, and I also don't have to worry that someone will break the build when I'm not looking. So the extra work making things super safe would not pay off that much.

Except when I feel I'm losing grip on what I'm doing, either from having to cover many use cases, not being experienced, unstable dependencies, or risk of data loss. That's when I set up CI pipelines for my personal projects.

View on HN

Every third party tool (or library dependency, by the way) is something that will have to be well understood, maintained and fixed when broken. Which is why I try to avoid them for the most part in my personal and work projects.

When someone at work says "Hey, lets just use Xyz package I found online! It does just what we want!" you need to ask: Who fixes it when it causes a problem that stops us from shipping? Who does the security audit? What data does it collect, and to where does it send that data? What will adding it do to our software's performance? Who decides when to update it to the next version and verifies compatibility? Is its license compatible with our workflow/software?

All of a sudden, people are less excited about that great doodad they found on StackOverflow! I'm always troubled by the cavalier attitude about relying on external tools and library dependencies. Yolo just pull it in! In some cases it might be the right decision, but not always. And, avoiding third party stuff is not always just blind NIH mentality: There are costs to depending on someone else for your project.

If you use third party libs with the appropriate licence then your the one that fixes it, just the same as if you rolled your own.

If you rolled your own, you invest your time to learn about the problem domain. If you use third party libs, you invest your time to learn about its interface/behavior. That is usually much more ephemeral knowledge. It is good tradeoff if the library does some heavy lifting, but that is not always true.

I strongly agree that bringing in new dependencies is not a small consideration. But at the same time, third-party dependencies will always be necessary and by carefully choosing those that are best suited for the job, you might be able to get a net reduction in complexity.

Old, established third-party dependencies are not necessarily better for the job than new, trendy dependencies. Their entrenched nature can be an advantage and also a limitation. And when you roll it yourself, then that is of course the newest and least established solution of all.

The cost of the alternative : doing it yourself, is also often underestimated.

"It's just a simple JSON parser, we can write our own" is a dismissal that can sink you down a rabbit hole of bugs and future technical debt.

The most important thing about using a third party library is that its easy to replace with another one if it doesn't work out.

Don't let third party data types or dependencies leak out of the module where you use them, for example via an API, and things go a lot smoother

Reply on news.ycombinator.com