SuperPumpup (dot com)
General awesomeness may be found here.

14 December 2014

Internalizing Dependencies

So I saw an interesting conversation today on Twitter between @DHH and @thijs this morning. They were discussing the NewRelic IPO and the subject got around to running ancient Rails versions, and the fact that a lot of the migration projects from Rails 2.3 have been driven in large part because of the movement of the surrounding ecosystem (read, gem updates).

I've upgraded a big application from Rails 2.3 to 3.0 and didn't enjoy it. It wasn't really necessary for the "application" per se, but the gems around it were aging and full of holes that had been patched and external API's that they had hooked to were changing, etc.

Then, I was working on a project this morning that uses a great Javascript library that I needed to add some functionality deep into the guts of. I figured I'd just "spike out" putting the code where it made sense to be, then see about "injecting it" after I was sure I could make happen what I needed to.

But then, once I had put the code where it "wanted" to be, I found something that was pretty well-factored, logical, and most importantly, worked. So then the idea of grappling for another half-day of trying to "inject" that functionality, I decided that maybe it makes a lot more sense to just "consume" that dependency.

It's about a 500 LoC JS library (so, all one file) and it seems like by just changing some things in the README, moving that file from /vendor/assets/compenents/whatever to app/assets/components I could basically "consume" this library that is actually pretty core to this project. I "lose" the ability to just merge in upstream fixes, but the bet that I'm making here is that this core functionality (that's now extended quite a lot) is going to be a real liability on the "balance sheet" of the application.

It seems like we like to just ignore the risk and liability that we have with a long Gemfile and celebrate how great it is that in Rails you can have such complex applications with "so little code" because you can pull in 2, 5, 10, 20k LoC dependencies with such ease and not really understand the risk and liabilities of the application.

It's interesting to think about, and something I'll reach for more often. Rather than struggle to "inject" changes into applications, why just "consume" them - bring them onto the "balance sheet".