Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never use a dependency that you could replace with an afternoon of programming

blog.carlmjohnson.net

Post reply on HN
Print view View original

301–310 of 333 posts

Re: Never use a dependency that you could replace with an afternoon of programming

#301

Post by greyhair »

avmich wrote: post #76
vlovich123 wrote: post #59

Earlier quoted context omitted.

Depends how your dependency management system works. Some times it can take an afternoon or more just to integrate it into your build for c/c++

Somehow here we assume a good programmer routinely makes errors in time estimation by an order of magnitude, yet conveniently forget cases when, say, a non-trivial GPL library is embedded as a dependency into a project, and customer is asking for code, and legal team runs with hairs on fire because company didn't plan to release the code...

But that is a completely different topic. Licensing is an issue, yes, but that is part of the upfront decision process.

In this day an age, this many years into open source licensing, if your team is not on top of that from day one, they have failed as a team.

I worked at Bell Labs from the mid 1980s to 2000, and by early 1990s (1992? 1993?) they already had a full internal team dedicated to open source licensing issues, including training and consulting. That was 27 or 28 years ago. Before some of the developers on this thread were even born.

Re: Never use a dependency that you could replace with an afternoon of programming

#302

Post by nailer »

earthboundkid wrote: post #122

OP here: A lot of people are objecting, "What if you estimate wrong, and it takes more than an afternoon?" This objection is very bad. It is not possible to add a new dependency in less than afternoon because you need to evaluate alternatives, test it, learn how it works, make sure it's not accidentally GPL, etc. So there are not two methods, the less-than-an-afternoon method and the more-than-an-afternoon method. Th…

> It is not possible to add a new dependency in less than afternoon because you need to evaluate alternatives, test it, learn how it works, make sure it's not accidentally GPL, etc

For a small module that would take less than an afternoon. Checking a module license takes less than it took to read the comment.

Re: Never use a dependency that you could replace with an afternoon of programming

#303

Post by luizfzs »

It works great up to the point that you have one week to deliver a feature, and that one afternoon is the difference between you delivering a half-tested or well-tested feature.

Also, as pointed by other comments, people are generally not good at estimating.

Re: Never use a dependency that you could replace with an afternoon of programming

#304

Post by greyhair »

hinkley wrote: post #185
greggman3 wrote: post #143

Earlier quoted context omitted.

It really depends (haha) on what it is. I needed to copy a file in npm scripts. can't use `cp` because that fails on windows. I looked on npm to copy a file. First hit 197 dependencies, 1170 files, 47000 lines of JavaScript. all I needed was const fs = require('fs'); fs.copyFileSync(process.argv(2), process.args[3]); Taking 197 dependencies means 197 things that need updates several times a year at a minimum. Any of…

In the interests of some sanity, I would like to say, all in one spot, that these are not mutually exclusive - You should absolutely use community-supported tools to solve your problems. - You should substitute idiomatic code for libraries. You have made an argument for the latter that does not detract from the former.

This needs about 1000 upvotes. So much truth in so few words.

Re: Never use a dependency that you could replace with an afternoon of programming

#305

Post by fastball »

vorticalbox wrote: post #93
aziytuiam wrote: post #8

A hundred afternoons later my small application is finally completed; now I must maintain update and document it all for ever rather than relying on third party components. What I really wish is people would look closer to home; for example use some of the thousands of functions that ship with your operating system before downloading a package.

I have this problem at work with our node apps. With things like reduce, map, the like their is less need to rely on lodash or underscore for them.

The problem with node is that it doesn't ship with a stdlib.

That being said, lodash has worked great for utility stuff. It encapsulates like 99% of utility functions I need in my apps.

Re: Never use a dependency that you could replace with an afternoon of programming

#306

Post by samus »

dogma1138 wrote: post #224
fernandotakai wrote: post #161

Earlier quoted context omitted.

taking in consideration how business work, in a few years you are going to have a full parser in your hands.

With all the technical debt associated with it, which is the problem basing your project on a dependency that would allow you to easily scale and add features is a huge benefit. This is like saying you should roll your own crypto because you only need to do a very limited sub set of crypto operations so why use something like NaCl or Tink.

Encryption is a terrible edge case. If you are forced to half-ass encryption, you should seriously question the project requirements. Bad encryption can be worse than none at all. Things won't end well if data security is treated as a detail.

Re: Never use a dependency that you could replace with an afternoon of programming

#307

Post by luord »

Controversial to say the least. While I know the value of in-housing as much code as possible; I only think it should be done once (https://luord.com/2016/06/25/nih).

After that one time, I've strove to limit the in-house code only to the actual domain and business rules of the application/system.

Re: Never use a dependency that you could replace with an afternoon of programming

#308

Post by jimmynest »

Izkata wrote: post #272
majewsky wrote: post #212

Earlier quoted context omitted.

That's not JSON, though. It's absolutely something else. Maybe a JS snippet. Maybe YAML. Definitely not JSON, though. (Some JSON libraries do have option flags, but usually it's about whether, during deserializing into a known type, unknown fields are an error or silently ignored. Or whether C-style comments are an error or considered as whitespace.)

> Maybe a JS snippet. While acceptable, also misleading: JS only does string keys, but unlike JSON it'll convert whatever it's given into strings. Not a problem most of the time, since it'll do the same conversion for both accessing and setting, but good to be aware of if you're doing something like iterating Object.keys()

I use https://jsonformatter.org/json-parser sometime to parse json and to validate.

Re: Never use a dependency that you could replace with an afternoon of programming

#309

Post by quest88 »

nayuki wrote: post #107
jdmichal wrote: post #34

My rule is, don't use a dependency to implement your core business. Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions. Everything else you write is just fat waiting to be cut by someone who…

> don't use a dependency to implement your core business In logic language, you're saying "If X is your core business, don't outsource X". > Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions…

What is the point you're trying to make?

Re: Never use a dependency that you could replace with an afternoon of programming

#310

Post by quest88 »

ori_b wrote: post #68
andrewstuart wrote: post #36

Earlier quoted context omitted.

I came here just to say this. "This'll take an afternoon" - three weeks later...... Programmers are notorious for this. BUT even apart from this problem ... you absolutely should use every dependency you can that will save you time. Try to write less code not more. When you write code you write bugs, add complexity, add scope increase need for testing, increase the cognitive load required to comprehend the software,…

And when you run into a bug or design problem in a dependency of a dependency of a dependency? It often takes less time to write some code than to understand someone else's code. Most programmers I've worked with get lost easily when jumping through layers of other people's code. I certainly do. Solid, well tested dependencies that solve hard problems are worthwhile. But dependencies have a cost in debuggability and…

Cross that bridge when you get there.
Post reply on HN