Bulky, heavy, fat ORMs

A long time ago, I wrote the fol­low­ing in the de­scrip­tion of Or­seis.

I nev­er liked ORMs. They are bulky, heavy, fat. They build SQL queries be­hind my back, and I don't like it. I want to be in con­trol.

Re­cent­ly, a per­son asked on SE.SE how is it pos­si­ble that we still write SQL by hand, de­spite the pres­ence of lots of very ca­pa­ble ORMs. An in­ter­est­ing as­pect in this ques­tion is the com­par­i­son with oth­er do­mains where de­vel­op­ers rely heav­i­ly on an ab­strac­tion lay­er: in gen­er­al, one doesn't send an e-mail by play­ing with SMTP, and doesn't write web ap­pli­ca­tions by pro­cess­ing raw HTTP.

This leads to a sub­ject of ab­strac­tions: what do they bring, how do they leak, and what it means for busi­ness. Al­low me to start with a short sto­ry which has noth­ing to do with ORMs: my ex­pe­ri­ence with ASP.NET Web­Hooks li­brary.

A few months ago, I was con­tribut­ing to an API which need­ed to re­ceive some events from the un­der­ly­ing API. Web­Hooks be­ing a hype, it was de­cid­ed to use them for the task, and since the API uses ASP.NET Web API, any­thing with “ASP.NET” in its name was a manda­to­ry choice any­way. So I strug­gled with ASP.NET Web­Hooks for a week be­fore re-im­ple­ment­ing a large part of the func­tion­al­i­ty we need­ed by hand.

From there, it ap­peared that:

• The li­brary is doc­u­ment­ed very bad­ly, which is not sur­pris­ing from any­thing re­leased by Mi­crosoft in the last five years, by op­po­si­tion to the ear­ly .NET Frame­work as­sem­blies which usu­al­ly had ex­cel­lent and com­pre­hen­sive doc­u­men­ta­tion.

• The li­brary is de­signed specif­i­cal­ly for nar­row “mar­ket­ing” sit­u­a­tions. Want to re­ceive no­ti­fi­ca­tions from Slack or Face­book? You can do it with­in min­utes, writ­ing min­i­mal amount of code. Want to do some­thing which is out­side those show­case sit­u­a­tions? You ei­ther need to tweak and tear the li­brary a lot, or even end your­self be­ing on your own.

• The li­brary makes easy things ex­treme­ly com­pli­cat­ed. By adding things such as HMAC ver­i­fi­ca­tion (which we didn't need any­way, but which couldn't be dis­abled), the li­brary makes it very com­pli­cat­ed to in­ter­act with it from any­thing else than the li­brary it­self. In oth­er words, I wast­ed lit­er­al­ly days try­ing to make my own im­ple­men­ta­tion work on one side, in­ter­act­ing with Mi­crosoft's li­brary on the oth­er, while I could im­ple­ment a sim­ple no­ti­fi­ca­tion mech­a­nism my­self in a mat­ter of hours.

This is an ex­cel­lent ex­am­ple of a harm­ful ab­strac­tion. It pre­tends to sim­pli­fy things, and it ac­tu­al­ly does as soon as you stay with­in its lim­its—with­in the area the ab­strac­tion was ex­plic­it­ly de­signed for. With­in this area, it saves you time, and a lot of time. Hours of work writ­ing code which doesn't nec­es­sar­i­ly have enough tests to be re­lied upon, you write two-three lines of code, and that's it; it works, flaw­less­ly. How­ev­er, as soon as you need some­thing else, the ab­strac­tion harms you and makes you waste days or weeks, or sim­ply makes it im­pos­si­ble to do what you want.

This phe­nom­e­non is glob­al, and prac­ti­cal­ly every li­brary or frame­work has this flaw. Help­ing a team who uses An­gu­lar, I'm of­ten sur­prised that they pre­fer to have a poor user in­ter­face, be­cause do­ing oth­er­wise would of­fend An­gu­lar. If a choice of a frame­work means that I can't do cer­tain things I can do with a dozen lines of code with jQuery, I say: “throw the frame­work.” Users mat­ter more than frame­works.

Every ab­strac­tion could short­en the amount of time it takes to de­sign a part of soft­ware, and make it longer to de­sign oth­er parts. Take a sim­ple ex­am­ple. Green bars in­di­cate the time it takes to de­vel­op six parts of a soft­ware prod­uct with­out us­ing a spe­cif­ic frame­work or li­brary. Blue bars show the time it takes to de­vel­op the same parts while us­ing the frame­work or li­brary.

Any suc­cess­ful sales­man would em­pha­size how the li­brary helps with the part E. It's fan­tas­tic: with the help of the li­brary, in­stead of spend­ing time de­vel­op­ing all the stuff your­self, you just write a line of code and, mag­i­cal­ly, it works.

The same sales­man won't men­tion any­thing about the parts A and C which takes much more time, but where the li­brary doesn't help. And, ob­vi­ous­ly, he will stay silent on the neg­a­tive con­se­quences of the li­brary on the parts B, D and F. But if you do the math, it ap­pears that the li­brary is maybe not that fan­tas­tic af­ter all:

Agreed, it saved you time be­cause you didn't have to de­vel­op the part E, but over­all, you spent more time adapt­ing the prod­uct to this li­brary. Not nice.

There are sit­u­a­tions where a giv­en li­brary only wastes your time. My ex­pe­ri­ence with ASP.NET Web­Hooks is ex­act­ly that: days in­stead of hours of work. Sev­er­al fac­tors could cause that. In some rare cas­es, it comes from poor­ly writ­ten, poor­ly doc­u­ment­ed li­braries. More fre­quent­ly, it comes from the in­ad­e­qua­cy be­tween the tasks the li­brary is de­signed for and the con­text where the li­brary is used. This is why it is es­sen­tial for the au­thors of a li­brary to be very spe­cif­ic about the li­brary lim­its. This is ex­act­ly what I did when re­leas­ing the nicecall li­brary:

Note that nicecall is not a sub­sti­tute to subprocess, be­cause much of subprocess func­tion­al­i­ty doesn’t ex­ist. For in­stance, one can’t use stdin or pipes with nicecall. The goal is not to re­place subprocess, but only to pro­vide an easy way to do the most com­mon tasks.

In the same way, the au­thors of ASP.NET Web­Hooks li­brary should have spec­i­fied that the li­brary is good to re­ceive no­ti­fi­ca­tions from GitHub or Azure, but is a poor choice for any­thing out­side the very ba­sic cas­es. Ob­vi­ous­ly, many au­thors of li­braries are re­cal­ci­trant to put clear in­for­ma­tion about the li­brary scope, be­cause of a sales­per­son men­tal­i­ty.

How a li­brary or a frame­work would im­pact your soft­ware prod­uct de­pends on hor­i­zon­tal and ver­ti­cal ad­e­qua­cy and on hor­i­zon­tal and ver­ti­cal cost.

• Hor­i­zon­tal ad­e­qua­cy means that the de­pen­den­cy helps you with a broad range of tasks. .NET Frame­work or J2E are good ex­am­ples: they are huge, and have so much stuff in it that you rely on them for near­ly every­thing, from cre­at­ing a sub­string from a string to stream­ing data to cre­at­ing ZIP archives. Web frame­works such as ASP.NET MVC or Flask gen­er­al­ly have a good hor­i­zon­tal ad­e­qua­cy for web ap­pli­ca­tions. Now, if you're writ­ing a desk­top ap­pli­ca­tion, hor­i­zon­tal ad­e­qua­cy of ASP.NET and Flask is zero.

• Ver­ti­cal ad­e­qua­cy means that the de­pen­den­cy helps you a lot. Take a li­brary which sends e-mails. Its scope is very nar­row: it won't cre­ate CSS bun­dles or help me im­ple­ment CSP for my web ap­pli­ca­tion, mean­ing that its hor­i­zon­tal ad­e­qua­cy is low. How­ev­er, its ben­e­fits are tremen­dous if my goal is to send punc­tu­al e-mails: I don't need to know SMTP pro­to­col to send e-mails. If my goal is, in­stead, to broad­cast thou­sands of e-mails per sec­ond, the ver­ti­cal ad­e­qua­cy is close to zero: there is no real help from the li­brary, as I would still have to learn the un­der­ly­ing pro­to­cols, spam fil­ter­ing, and dozens of oth­er as­pects if I want to suc­ceed.

• Hor­i­zon­tal cost is the size of the im­pact of the ab­strac­tion on your ap­pli­ca­tion. If you use a li­brary to send e-mails from a web ap­pli­ca­tion, the hor­i­zon­tal cost is close to zero: you only have an ad­di­tion­al de­pen­den­cy you have to main­tain. If, on the oth­er hand, you use an MVC frame­work, an im­por­tant part of your ap­pli­ca­tion is af­fect­ed, since it forces you to use the MVC pat­tern. An­oth­er ex­am­ple is Share­Point: tried to get rid of Share­Point from an ap­pli­ca­tion writ­ten for it in the first place?

• Ver­ti­cal cost is the cost added to the task by the ab­strac­tion. With e-mails li­brary, this cost is very low. With li­braries such as RxJS, the cost is very high, be­cause you have to learn a new par­a­digm (if you al­ready knew the par­a­digm and every per­son who will join your team in the fu­ture will know it too, then the cost drops to near­ly zero).

We would all pre­fer deal­ing with ab­strac­tions which have a large hor­i­zon­tal and ver­ti­cal ad­e­qua­cy (i.e. they have all we need, and do it great), and no hor­i­zon­tal and ver­ti­cal cost (i.e. they don't con­strain us in the parts of the ap­pli­ca­tion where we don't need those ab­strac­tions and they are easy to set up). But more of­ten than not, ab­strac­tions tend to be cost­ly, and bring ques­tion­able ben­e­fits in nar­row sit­u­a­tions.

What does all that have to do with ORMs?

ORMs have a small hor­i­zon­tal cost but a con­sid­er­able ver­ti­cal cost.

• Small hor­i­zon­tal cost: high qual­i­ty ORMs such as En­ti­ty Frame­work do know how to avoid im­pact­ing your whole ap­pli­ca­tion; they re­strict them­selves to the ar­eas where you want them to be, and even make it pos­si­ble for you to by­pass them when you need to.

• Con­sid­er­able ver­ti­cal cost: ORMs are com­plex. LINQ to SQL was sim­ple, but not very pow­er­ful. With pow­er, comes com­plex­i­ty, as En­ti­ty Frame­work shows us. You can do a lot, but there is a learn­ing curve for that. WCF was an­oth­er great ex­am­ple: very pow­er­ful, it could lead you to hours of head bang­ing and des­per­ate Stack­Over­flow brows­ing.

As for their ad­e­qua­cy:

• As the hor­i­zon­tal ad­e­qua­cy grows, the ver­ti­cal cost grows too. This is the con­se­quence of the fact that ORMs are a leaky ab­strac­tion: they do tend to let you do lots of things, but in or­der to do those things, you have to know well the un­der­ly­ing tech­nol­o­gy (in this case, SQL and the data­base), and, in ad­di­tion, you have to learn how such or such thing is im­ple­ment­ed in the ORM it­self. For in­stance, if I need to op­ti­mize a slow search on a table con­tain­ing lots of rows, not only do I need to know what in­dex­es are and how to use them, but I also need to find how to tell to En­ti­ty Frame­work to put an in­dex on a spe­cif­ic col­umn.

• The ver­ti­cal ad­e­qua­cy could be good for very nar­row sit­u­a­tions: the sim­ple ones, the aca­d­e­m­ic ones. Se­lect­ing all prod­ucts where a price is be­tween this and that? Can do that. As soon as one starts mov­ing to more com­plex sit­u­a­tions, the ver­ti­cal ad­e­qua­cy de­creas­es, and in more and more cas­es, you'll find that it's just eas­i­er to write the SQL query by hand than to tweak your fa­vorite ORM.

I would love an ORM which could fig­ure how to store the data, be able to cross the bound­aries of SQL and move to data­bas­es such as Mon­goDB or Re­dis as well. I would love it to an­a­lyze the data and the re­quests and de­ter­mine how the schema should be op­ti­mized based on the cur­rent us­age. I would love sim­ply telling: “Hey, ORM, please store this ob­ject for me” or “Hey, ORM, could you tell me all the records of this type for the last two weeks” and nev­er have to look un­der the hood. Un­for­tu­nate­ly, this isn't hap­pen­ing soon.

What hap­pens soon is that ORMs stay among the great tools which do a great job in spe­cif­ic sit­u­a­tions, for spe­cif­ic pro­jects. As I don't de­vel­op in As­sem­bler, be­cause Java or Python com­pil­ers do a much bet­ter job for me, I hard­ly see my­self writ­ing SQL by hand for an or­di­nary busi­ness ap­pli­ca­tion. But there are cas­es where you need to dive into As­sem­bler be­cause you need spe­cif­ic per­for­mance op­ti­miza­tions, and there are cas­es where you need to write SQL by hand. Dur­ing my ca­reer, it ap­peared that none of my pro­jects led me to write As­sem­bler code, and that near­ly every pro­ject I did led me to hand-made SQL. Pos­si­bly de­vel­op­ers work­ing on em­bed­ded soft­ware do use As­sem­bler and don't write SQL. YMMV.