Hacker News Reader

I work on some really big projects in the wild for various clients in ruby on rails and they have so many gems that often I find unused gems they are afraid to remove them in case it actually is being used, but you know what? They were moving forward with features - their user base was happy and their product worked for the most part.

You know what kinds of projects I see fail? The ones who try to architect everything using a core set of libraries and build everything themselves. I've seen hugely funded projects with years of development burn for that very reason.

I know I'm just a single datapoint, but it's worth mentioning that there exists projects that absolutely will do better in the long run with just installing all the gems.

> often I find unused gems they are afraid to remove them in case it actually is being used,

I've worked on code-bases of small to medium size where people were afraid to remove self-written code because nobody knew if the code is actually called somewhere. It's not actually the gem that's the problem - it's being diligent. If you need a gem's function add it as top level dependency, don't rely on some other gem depending on it. require the code explicitly everywhere you use it. That way you can at least search your code base for it. Be equally diligent when removing code: Remove all code that only this code depended on. Other than that: Don't be afraid to break stuff.

> This "let someone else do the work, get it from a gem" mindset is what kills long lived projects

If you replace "gem" with "library", this actually makes a lot of sense. It saves time to reuse existing (high quality) software.

Plenty of ecosystems do just fine with this mindset, starting with the JVM and .net.

The problem is specifically Ruby and the gems system.

More specifically, the problem is the combination of Ruby making it very easy to monkey-patch and apply magic, and a community which more or less ubiquitously encourages gem authors to use those facilities as promiscuously as they like. Either in isolation would be dangerous; the combination is lethal.

> Senior/Lead devs need to carefully curate what a projects foundation is. A strong, well designed foundation means you have something solid to build on. If you don't understand what's in your deps, haven't read their code, see how often it's updated and how many people actively use it, and can say you are using 80% or more of the code in it then don't use it.

Having to deal with my share of poorly supported components in Django/DjangoCMS, I can confirm your observation for Python. But betting on the wrong opensource component is often better from betting on the wrong proprietary technology. It comes with the territory.

> Writing your own code is often the best route since it fixes your exact use case, no matter the language, libraries or frameworks being used.

The problem is not you supporting your own code versus you supporting the code of a random dude from Internet, the problem is when you move on to the next job and some poor guy has to support and fix bugs in your code from 3 years ago. In my experience the average quality of community components and components developed in-house are not that different.

Personally I wish project managers starting caring more for life-cycle planing.

This kind of thinking is how you end up with 8 zillion job-securing lines of custom frameworks-within-frameworks and stuff like:

  def isTrue(x):
    if x:
      return true
    else:
      return false

Code is debt: https://blog.codinghorror.com/the-best-code-is-no-code-at-al...

Reviewing vendor libraries always a good idea, but you aren't going to make it very far as a "Senior/Lead dev" if you are constantly using someone's money to reinvent the wheel.

  $ tree node_modules