What makes performance decrease over time?

In an ex­cel­lent blog post, Niki­ta Prokopov shares his thoughts about “our in­dus­try’s lack of care for ef­fi­cien­cy, sim­plic­i­ty, and ex­cel­lence,” ex­plain­ing, among oth­ers, that year af­ter year, hard­ware be­comes more and more pow­er­ful, but ap­pli­ca­tions re­main slow or be­come slow­er.

I'm afraid I know what caus­es this phe­nom­e­non.

First cause: lay­ers of com­plex­i­ty

A few years ago, web de­vel­op­ment meant JavaScript, JQuery, and, some­times, a tiny amount of li­braries care­ful­ly cho­sen for a giv­en pro­ject. And that was it. If you were a be­gin­ner pro­gram­mer, you weren't go­ing far with that. If you were more skill­ful, you could slow­ly craft a large-size ap­pli­ca­tion, and by the time you fin­ished im­ple­ment­ing most of its fea­tures, you would know a lot about per­for­mance and op­ti­miza­tion.

To­day, we have An­gu­lar, and we have Re­act, and dozens of oth­er frame­works. On top of them, we have npm li­braries which are so easy to in­stall that most pro­jects start with dozens of de­pen­den­cies. Got a fea­ture in mind? There is an npm pack­age for it. No need to de­vel­op one your­self; just add a de­pen­den­cy. And then, one doesn't write in JavaScript; one uses Type­Script, or some oth­er fan­cy lan­guage be­ing fash­ion­able, which means that the de­vel­op­er nev­er wrote the code which is served to the clients and ex­e­cut­ed by the browsers.

The main­stream opin­ion is that all those frame­works and li­braries and lan­guages make web de­vel­op­ment much faster. With more than two years ex­pe­ri­ence ob­serv­ing the teams work­ing with those frame­works, li­braries and lan­guages, I would dis­agree. The time wast­ed set­ting up those lay­ers of com­plex­i­ty, mi­grat­ing from An­gu­lar­JS to An­gu­lar, dis­cussing how should re­dux be used, and try­ing to fig­ure out , through the lay­ers of com­plex­i­ty, the lo­ca­tion of a nasty bug, is quite im­pres­sive. The time saved by an ad­di­tion­al de­pen­den­cy or an ad­di­tion­al leaky in­ter­face? Not so much.

How­ev­er, those tech­nolo­gies are fash­ion­able, and there­fore broad­ly used. And, ob­vi­ous­ly, they add up not only to the com­plex­i­ty of the pro­jects, but also the size. Nowa­days, it is not un­usu­al for the most el­e­men­tary web pages to have a foot­print of sev­er­al megabytes. A few ex­am­ples:

• The home page of French rail­way com­pa­ny per­forms 119 re­quests for a to­tal of 2.8 MB (Ad­Block en­abled) and fin­ish­es af­ter 8.24 sec­onds.
• A sim­ple ar­ti­cle on Medi­um.com wastes 1.4 MB do­ing 53 re­quests, fin­ish­ing af­ter 7.89 sec­onds.
• Ama­zon's home page takes 305 re­quests us­ing up to 6.3 MB and tak­ing 4.67 sec­onds.
• FedEx home page per­forms 86 re­quests, trans­fer­ring 3.4 MB dur­ing 6.81 sec­onds.

Many of the young pro­gram­mers, when start­ing a new ap­pli­ca­tion, be­gin by adding frame­works, tools and dozens of li­braries. From scratch, even be­fore pro­vid­ing val­ue, the web ap­pli­ca­tion is heavy and slow. This is crazy, but fash­ion­able.

If only this was lim­it­ed to the In­ter­net. Desk­top ap­pli­ca­tions have the same prob­lem. Six years ago, I asked a group of IT stu­dents who learned C# for a few years if any­body knows how to cre­ate a sim­ple “Hel­lo, World!” con­sole ap­pli­ca­tion from scratch with­out us­ing an IDE. No­body was able to an­swer. A decade ago, I was cre­at­ing C++ desk­top ap­pli­ca­tions this way: the real desk­top apps with but­tons, text box­es, all that. To­day, when I see all the new lay­ers which grew around C# desk­top ap­pli­ca­tions, I'm not sure I would be ca­pa­ble of cre­at­ing a Hel­lo World us­ing just vi.

Mo­bile apps? Same thing. When I tried cre­at­ing An­droid apps, I was amazed at the quan­ti­ty of code which I had to com­mit to ver­sion con­trol af­ter cre­at­ing an emp­ty pro­ject. I'm un­able to un­der­stand any of it, and I have no idea about what is hap­pen­ing un­der the hood. I know where to click in the IDE when things don't work, be­cause I googled it. Does it make me a good de­vel­op­er? I hard­ly think so.

Sec­ond cause: de­vel­op­ers' miss­ing skills

Imag­ine your­self thir­ty years ago, in 1988. You have to wait for sev­en years to start to use Java. There is C++, but there are no smart point­ers yet. There is no Stack Over­flow. You can't just copy-paste code you find on the In­ter­net, and you have to read books to learn things, be­cause if you don't learn, C++ will bring you a few sur­pris­es. Be­cause lan­guages are low lev­el, you have to have a ba­sic un­der­stand­ing of how com­put­ers work. You have to be if not a great de­vel­op­er, at least quite skill­ful at what you do if you want to suc­ceed.

Not any longer. With all the things ab­stract­ing oth­er things which, in turn, ab­stract oth­er things, you can cre­ate ap­pli­ca­tions which kin­da work with­out any par­tic­u­lar skill. In­stead of learn­ing the ba­sic things about a com­put­er, you learn how to use a frame­work. In­stead of un­der­stand­ing the al­go­rithms and their quirks, you use li­braries. In­stead of un­der­stand­ing data struc­tures, you use a high lev­el frame­work which hides all the com­plex­i­ty.

And so, you ex­pect that those li­braries and frame­works will fig­ure out the in­ter­nals for you.

I stopped count­ing the num­ber of times I've seen wrong data types be­ing used in C# for se­quences. For some rea­son, every­thing be­came a List<T>, un­less it's a Dictionary<T>. I'm still sur­prised when en­coun­ter­ing that “pro­fes­sion­al de­vel­op­ers” who have more than eight years ex­pe­ri­ence with C# don't know that there is such a thing as a Set<T>, or that they use a sim­ple list for a re­cur­sive method which should rely on Stack<T> or Queue<T>, or that they are un­able to ex­plain what a LinkedList<T> is and in which cas­es one would like to use it.

So when those “pro­fes­sion­al de­vel­op­ers” are writ­ing an ap­pli­ca­tion which uses more CPU or mem­o­ry than an av­er­age app, they still use wrong data struc­tures by de­fault, be­cause this is what they have done their whole life. Then, when the app be­comes slug­gish, they buy new hard­ware to make it per­form faster.

Third cause: em­pha­sis on hard­ware

De­vel­op­ers are paid well enough. They can af­ford buy­ing hard­ware and gad­gets. Why, my mo­bile app is run­ning slow? I think this is an op­por­tu­ni­ty to pur­chase iPhone X. Brows­ing web­sites is not fun any longer? Ob­vi­ous­ly, I haven't pur­chased a new PC for the last four years!

De­vel­op­ers are al­ways com­plain­ing about de­vices. No enough mem­o­ry. SSD is not fast enough. There is no USB 3. This is es­pe­cial­ly im­pres­sive at work­place. My cur­rent col­leagues have lap­tops I could only dream about three years ago, and they still find rea­sons to com­plain.

This overem­pha­sis of hard­ware cre­ates ex­cus­es. Thir­ty years ago, you wrote an app, and then you nec­es­sar­i­ly tried to op­ti­mize it. By do­ing it again and again, you learned how to do it. To­day, many of so called “pro­fes­sion­al de­vel­op­ers” have no idea how to op­ti­mize things: they don't know the pat­terns they should ap­ply, and they don't know the tech­nol­o­gy well enough.

Pat­terns seem to be the most wor­ri­some thing. For too many de­vel­op­ers, op­ti­miza­tion con­sists of telling your­self one day that you should make some piece of code faster, and start chang­ing the code ran­dom­ly, based on your as­sump­tions that those changes will make it faster. No need to mea­sure any­thing. Do the change any­where in the code, and claim that it's op­ti­mized now.

The as­sump­tions should prefer­ably be low lev­el, such as “I'm sure switch is faster than a lookup, so I'll re­place all the oc­cur­rences of a lookup by a switch.” Or some­thing like: “I should re­al­ly re­move those in­ter­me­di­ary vari­ables, and in­line those meth­ods; do you imag­ine how much time is spent do­ing a call to a method?”

They don't know how to use a pro­fil­er. The no­tion of bot­tle­neck is un­fa­mil­iar for them. And they are tru­ly con­vinced they are smarter than the com­pil­er.

Con­clu­sion

Those three caus­es: the crazy lev­el of com­plex­i­ty, the poor skills of soft­ware de­vel­op­ers and the lack of ex­per­tise in op­ti­miza­tion, caused by the em­pha­sis on hard­ware, leads to the sit­u­a­tion we have now. I'm not sure if this sit­u­a­tion is that bad. I'm in­clined to think that hard­ware be­com­ing cheap­er and cheap­er, the in­crease at this lev­el can com­pen­sate the loss at soft­ware lev­el. I also be­lieve that com­pe­ti­tion may bring fo­cus to faster, small­er ap­pli­ca­tions, de­vel­oped by more skill­ful de­vel­op­ers who care more about their users.

How­ev­er, there may be a dif­fer­ent side to it. While hard­ware be­comes cheap­er over time, there is a dif­fer­ence be­tween what an av­er­age Amer­i­can de­vel­op­er can af­ford, and what is avail­able for a low-in­come per­son from a poor coun­try, and the gap could grow. I don't think that telling that we—the IT pro­fes­sion­als—don't care about this sec­ond cat­e­go­ry of per­sons is a good thing. An­oth­er gap which will grow is the one be­tween large com­pa­nies which can af­ford the best de­vel­op­ers, and the com­pa­nies which can­not. While hype be­longs to the apps de­vel­oped by the first group, the ap­pli­ca­tions used eight hours per day by ac­coun­tants, lawyers, den­tists, and hun­dreds of oth­er pro­fes­sions are de­vel­oped by the sec­ond group.

In or­der to stop this de­cline, it is es­sen­tial to:

• Teach the fel­low de­vel­op­ers the ba­sic, low lev­el things. Two of my col­leagues (eight years ex­pe­ri­ence in soft­ware de­vel­op­ment) ad­mit­ted that they learned As­sem­bly lan­guage in col­lege for a few hours. Not days. Hours. Most de­vel­op­ers have no ex­pe­ri­ence with C or C++ or any low lev­el lan­guage. Many web de­vel­op­ers don't un­der­stand HTTP. They should prac­tice writ­ing apps at low lev­el. No frame­works or fan­cy li­braries al­lowed.

• Data struc­tures should be a manda­to­ry course for every stu­dent. Hir­ing in­ter­views should em­pha­size ques­tions about data struc­tures, mem­o­ry foot­print and Big O no­ta­tion, check­ing that the can­di­date has ba­sic skills, mak­ing him ca­pa­ble of un­der­stand­ing the reper­cus­sion, in terms of per­for­mance, of a giv­en choice he makes dur­ing de­vel­op­ment.

• Op­ti­miza­tion should be a first-class cit­i­zen among the re­quire­ments, and de­vel­op­ers should be taught what pat­terns they should ap­ply to en­sure com­pli­ance with per­for­mance re­quire­ments. In­ter­view­ers should check if a can­di­date has a ba­sic un­der­stand­ing of com­pil­er op­ti­miza­tions and that he knows what be­longs to pre­ma­ture op­ti­miza­tion and what is just com­mon sense.