Hidden costs of freeware libraries

There are so many open source li­braries and frame­works out there for de­vel­op­ers to down­load and use that it is very tempt­ing to use them uni­ver­sal­ly, with­out ask­ing one­self if a giv­en li­brary or a frame­work is re­al­ly nec­es­sary for the pro­ject. With the pop­u­lar­i­ty growth of pack­age man­agers, it be­came ex­treme­ly easy to add an­oth­er de­pen­den­cy to a pro­ject, en­cour­ag­ing even more the be­hav­ior where one has to jus­ti­fy not us­ing a third-par­ty com­po­nent. Fi­nal­ly, the per­for­mance im­pact of just an­oth­er lay­er is so small that no­body would care about that for most prod­ucts any­way.

Every li­brary and frame­work, how­ev­er, has an in­her­ent cost, which is paid dur­ing the whole lifes­pan of the prod­uct. This cost man­i­fests it­self in four ways:

1. One has to learn the com­po­nent, its quirks, its tricks, its in­com­pat­i­bil­i­ties. If the com­po­nent is main­tained, new ver­sions are re­leased, in­tro­duc­ing new fea­tures to learn, and new is­sues to han­dle, so learn­ing be­comes a con­stant process, which can take, for some of them, con­sid­er­able time. One should note that con­trary to REST APIs, li­braries, and more­over frame­works, have a large and in­tru­sive in­ter­face which could be very com­plex.

   ^{Of course, it all de­pends on the APIs, the li­braries and the frame­works; some APIs such as Ama­zon S3 could get rather com­plex, but their in­ter­face is still small com­pared to the frame­works such as Lar­avel.}

2. Every li­brary and frame­work be­ing de­signed for the pur­pos­es slight­ly dif­fer­ent from the pur­pos­es of a spe­cif­ic pro­ject us­ing it, con­straints need to be cir­cum­vent­ed. This could ul­ti­mate­ly lead to a fork of the com­po­nent; for more ba­sic as­pects, it trans­lates into man-hours wast­ed search­ing of a way to cir­cum­vent a giv­en lim­i­ta­tion.

3. As a fur­ry friend, a com­po­nent seeks reg­u­lar at­ten­tion and care. New ver­sions should be de­ployed, ar­chi­tec­tur­al pref­er­ences should be fol­lowed. Every new ver­sion brings new sur­pris­es, and the code should be tweaked on reg­u­lar ba­sis to fit any­thing frame­work de­vel­op­ers throw at their users.

As an il­lus­tra­tion of those points, I re­cent­ly worked with a team of four de­vel­op­ers who main­tain a web ap­pli­ca­tion. The ap­pli­ca­tion is not that big: a few pages, a few high­ly in­ter­ac­tive forms, lots of AJAX—well, the rou­tine. It could be done with plain jQuery and jQuery UI, and some light­weight li­brary for data bind­ing. Those de­vel­op­ers, how­ev­er, have cho­sen the path of a war­rior—An­gu­lar­JS, Type­Script, and a few dozen of npm de­pen­den­cies, giv­en that I'm un­cer­tain of the pur­pose of more than half of them.

Well, one would say, what An­gu­lar­JS and oth­er things bring is what the team doesn't have to de­vel­op from scratch, and this is good. But there are a few is­sues:

• One of four de­vel­op­ers spends prac­ti­cal­ly all the time deal­ing with pure­ly tech­ni­cal as­pects re­lat­ed to An­gu­lar­JS and the li­braries. Oth­ers de­liv­er fea­tures need­ed by the users of the web app, but not him: he's too busy up­grad­ing to the next ver­sion of some­thing, or tweak­ing some­thing else, or fix­ing code which was bro­ken by the up­grade to the next ver­sion of a pack­age. When all npm li­braries are up to date, he'll find that Type­Script needs to be up­dat­ed, and this leads to a glob­al fix­ing of some fan­cy things which were dep­re­cat­ed by the new Type­Script. And when this is fixed, it ap­pears that one of the li­braries is in­com­pat­i­ble with the new code, and should be tweaked.

  As if it wasn't enough to waste one per­son's time for that, he con­stant­ly re­quires help from oth­er mem­bers, or even from oth­er teams, mean­ing even more mon­ey thrown with­out bring­ing any ac­tu­al val­ue to the users.

• And of course there are new li­braries, and new test­ing frame­works, and... new stuff. Since new is al­ways ex­cit­ing, one should ab­solute­ly use it in the pro­ject, so from time to time, new fur­ry pets join us, re­quir­ing at­ten­tion and care as well.

• I prac­ti­cal­ly don't know An­gu­lar­JS, so it is not sur­pris­ing that it takes me hours to do things I would do in a mat­ter of min­utes with plain jQuery. What sur­pris­es me is to see the time my col­leagues spend on prob­lems which could be solved very fast with­out all those fan­cy frame­works and li­braries. There is some weird stuff where no­body knows how to han­dle a lim­i­ta­tion of Type­Script or An­gu­lar­JS, and then some­one ends up hack­ing a thing which doesn't look nice or main­tain­able.

• Leaky in­ter­faces suck. Type­Script made me waste nu­mer­ous hours, pre­tend­ing that it will han­dle some­thing in some way, while it would leak JavaScript as­pects through it; there­fore, I hate Type­Script.

• While those frame­works and li­braries do oc­ca­sion­al­ly re­duce the code the team needs to main­tain, there are cas­es where it adds too much need­less com­plex­i­ty. Main­tain­ing those parts of the code­base is com­plex, and usu­al­ly re­sults in con­stant code growth, lead­ing to tech­ni­cal debt in­fla­tion.

My im­pres­sion is that, over­all, those frame­works and li­braries tend to bring a slight ben­e­fit in terms of code main­tain­abil­i­ty com­pared to the same so­lu­tion de­vel­oped with bare jQuery, a few li­braries and a light­weight data bind­ing mech­a­nism, but the slight ben­e­fit is too mi­nor com­pared to all the is­sues.

I'm not cer­tain why we got at the point where the de­fault choice is to add an­oth­er li­brary. How­ev­er, I'm cer­tain that this is a wrong ap­proach. It makes prod­ucts rigid, and ul­ti­mate­ly wastes more time that it saves. Li­braries, and even more frame­works, should be se­lect­ed on the ba­sis of an ac­tu­al, ma­te­ri­al­ized need, and on a firm de­ci­sion that in­tro­duc­ing this de­pen­den­cy into the pro­ject will ben­e­fit more than writ­ing code from scratch. I'm not say­ing that things such as An­gu­lar­JS shouldn't ex­ist: what I'm say­ing is that they shouldn't be used un­til it be­comes clear that they bring a vis­i­ble ben­e­fit in terms of time-to-mar­ket, code main­tain­abil­i­ty, struc­ture, or what­ev­er mea­sur­able fac­tor mat­ters for a giv­en team. All those com­po­nents, de­spite be­ing free to down­load and play with, do have a cost, which trans­lates it­self in thou­sands of dol­lars per month for even a small team. There should be some­thing tru­ly valu­able they bring to be worth pay­ing that much to use them.