[ephramzerb]

The only way I see this as a Rails problem is that Rails makes it easy to get saddled with lots of external dependencies. Otherwise, it's a problem with how external dependencies are managed.

If it's not the number and quality of dependencies then it's the wrong type. I usually stay away from gems that provide syntactic sugar or provide an alternative to ruby / rails defaults. If I'm using 5% of some library, I'd rather write it myself and only address the 5% that I need. If it's not maintained, I stay away. Etc.

A little discipline on what gems get included would go a long way to solving the perceived problems. Gems are generally designed to solve a much more generic version of the problem you're trying to solve and maybe not even the exact same problem, if you're messing with the innards too much, that gem is probably not a good enough fit.

Less is always better when it comes to dependencies.

[Goladus]

Less is always better when it comes to dependencies.

Yes but I think the point here is that the environment you choose can make it hard or easy to avoid dependencies.

I totally agree on "less is better with dependencies" but there are clearly many programmers who don't want to "reinvent the wheel" and always use libraries first. And a lot of times, the programmers willing to piece together lots of different community libraries will be a lot faster initially. They're just incurring technical debt.

If you're part of a team of these programmers, you might not actually be able to convince everyone that "less is always better" with dependencies.

[mattmcknight]

So, it's not Rails that's the problem, it's the post modern software developers that would rather use a buggy, thinly supported library than try to write their own code...

[Goladus]

I'm not saying rails is a problem, but that there's value in the large, stable and well-tested standard library.

[jrockway]

I have a story about this.

One time, I went to the store and bought a bike wheel. But it didn't come with a little strip to protect the tube from the spoke nipples. So, I threw it away and built my own wheel. Actually, I first built metal-refining plant, and then I built my own wheel.

Oh wait, I died before I built the wheel, but at least i didn't incur any 'technical debt'. If I had to buy a separate piece of rim tape, my wheel just wouldn't have been right! It may have given me years of enjoyment, but who cares? Those other wheel makers did it wrong!

(Oh, and last time I checked, 'technical debt' didn't mean, "I didn't get to write a research paper about the internal string representation." But that was a long time ago...)

[Goladus]

I have a story about this, too.

I bought a wheel from a bike store without knowing anything about bike wheels or bike stores. The wheel collapsed on me 3 weeks later, I fell into traffic and a car ran over me, crushing my chest. I'm now rotting in a graveyard paying back my 'technical debt'.

Ok that's just a story. Here's an anecdote:

I spent the last 3 weeks, which I could have spent doing things far more interesting and productive, rebuilding Perl modules because so many perl programmers couldn't be fucked to write portable code and our dependencies appear to number 300 or more. (Nobody actually kept track, of course)

For example, somebody's script, somewhere, uses Array::Compare. It's a tiny module that compares arrays (length, index of different elements, etc.), which is like a first year computer science project. Version 1.18 is 500 lines (including docs+comments) and has one dependency: Carp, a core module. Version 2.01 of Array::Compare is 465 lines (including docs+comments) and requires Moose which itself has 23 other dependencies many of which are not core modules and some require compilation. If Array::Compare was part of a standard library, one that ships with the standard Perl distribution, this wouldn't have been a problem. It wouldn't use Moose unless Moose was also part of the core dist, at which point it wouldn't be a problem unless maybe I was compiling everything from sratch, which I'm not.

So I have to downrev that module and use the old version, or else introduce another new significant dependency (which did not compile successfully on my first couple attempts) or else track down the script and eliminate the dependency and check to see if the author is in punching distance.

That's just one example. There were also mismatched compiler flags, modules that didn't install on some days because tests required connections to webservers that were returning 500 errors-- all the kinds of minor problems that aren't that big of a deal when you are one developer installing only the modules you need to solve your immediate problem, but turn into a huge mess when there are 300+ of them.

That's technical debt coming due. (And I'm certainly not paying back all of it, I'm not compiling Perl from scratch I'm not manually finding every scrap of perl code on our systems to see which modules they still really need, etc.)

[jshen]

not an apt analogy. It's more like, I went to the store to buy a bike wheel and what I got was a bike wheel building kit that let me choose between plastic spokes, metal spokes, number of spokes, width of the rim, type of tire. But I had to figure out the magic incantation that produced the combo I wanted, which took almost as long as it would have taken me to build one wheel.