Users matter more than bytes and CPU cycles

There is some­thing com­plete­ly wrong in de­vel­op­ers' na­ture to be ob­sessed with per­for­mance to the detri­ment of every­thing else. It seems even that this com­pul­sive ob­ses­sion is not some­thing we ac­quire with prac­tice, since it af­fects even be­gin­ner pro­gram­mers. For ex­am­ple, a re­cent now-closed ques­tion post­ed on soft­wa­reengi­neer­ing.SE by a be­gin­ner who was ask­ing how to cre­ate a web­site with con­tent writ­ten by users in­clud­ed the fol­low­ing para­graph, em­pha­sis mine:

So when I man­age to con­vert user in­put to html code, how smart is to pop­u­late my data­base with html code? I mean con­nect­ing to data­base every time user opens up web­site is not very ef­fi­cient. Should I some­how em­bed that code di­rect­ly to html pages?

Un­for­tu­nate­ly, this ob­ses­sion some­times re­mains de­spite years of ex­pe­ri­ence in soft­ware de­vel­op­ment. Now that I think about it, in near­ly every case where I heard a col­league talk­ing about per­for­mance was when he was en­cour­ag­ing some fan­cy op­ti­miza­tion, with­out any proof that there is a per­for­mance prob­lem in the first place, and that the op­ti­miza­tion af­fects the cur­rent bot­tle­neck.

By it­self, it is not a huge prob­lem. When de­vel­op­ers waste time op­ti­miz­ing some code which wasn't caus­ing any slow­ness in the first place (or try­ing to op­ti­mize some­thing while mak­ing it only slow­er), the only con­se­quence is the in­creased cost for the per­son or the com­pa­ny who pays for the prod­uct. Poor over­all pro­duc­tiv­i­ty, ex­treme num­ber of bugs caused by ter­ri­ble work­ing con­di­tions, num­ber of fea­tures no­body wants, and oth­er ma­jor is­sues have a much high­er im­pact on the cost of soft­ware.

Where it be­comes a prob­lem, how­ev­er, is when de­vel­op­ers are work­ing against in­ter­ac­tion de­sign­ers un­der the pre­text that they want to do an op­ti­miza­tion. A few days ago, I had an ar­gu­ment with one of my col­leagues, which is very il­lus­tra­tive of this prob­lem.

I was work­ing on a part of the prod­uct which pro­vides a list of en­ti­ties to the user, and let the user fil­ter this list ei­ther by se­lect­ing a bunch of cri­te­ria, or by typ­ing some text. It was de­cid­ed, for some su­per­flu­ous rea­sons, to keep the list on serv­er side, and do an AJAX re­quest which in­clud­ed the fil­ter­ing pa­ra­me­ters. Fol­low­ing KISS, I de­cid­ed to launch an AJAX query every time the text field is changed, and see what would hap­pen in terms of per­for­mance and re­spon­sive­ness. What hap­pened is that the app re­spond­ed well, the AJAX queries be­ing rel­a­tive­ly fast. It felt par­tic­u­lar­ly re­spon­sive: as soon as the user typed, near­ly im­me­di­ate­ly the list of en­tries re­flect­ed what was typed.

And then one col­league saw this, and found that this is a ter­ri­ble idea. “Nah, you should use RxJS and pause for a while be­fore launch­ing a re­quest; this is how every­body does that!” he told me. I tried to ex­plain KISS and pre­ma­ture op­ti­miza­tion stuff, but there was no use talk­ing to some­one ab­solute­ly con­vinced that every­body does that.

The fact that every­body doesn't do that (at least Google Search doesn't) is ir­rel­e­vant here. What is im­por­tant is that he in­tu­itive­ly at­tempt­ed to make the ap­pli­ca­tion un­re­spon­sive for the users just be­cause he thinks that some­thing should be op­ti­mized for some imag­i­nary rea­son. For him, users shouldn't be tak­en in con­sid­er­a­tion, or at least, the users' needs come af­ter CPU cy­cles. What would hap­pen for the users as a con­se­quence?

• The ac­tion would look like search­ing in­stead of fil­ter­ing. For a user, search might take time; fil­ter­ing, how­ev­er, is im­me­di­ate. The user doesn't care if the ac­tion takes place in the brows­er or through an AJAX re­quest; if it's fil­ter­ing, it should be di­rect.

• The in­ter­face would look un­re­spon­sive. Those timers which launch an AJAX re­quest no more than every 500 ms. were imag­ined by pro­gram­mers, from pro­gram­mers' point of view and for their goals. When I type some­thing, and the app ran­dom­ly re­acts to what I type and oc­ca­sion­al­ly waits for half a sec­ond be­fore ac­knowl­edg­ing my ex­is­tence, the ap­pli­ca­tion is sim­ply im­po­lite to me.

This at­ti­tude which con­sists of putting bytes over per­sons is root­ed in de­vel­op­ers' cul­ture. They are so close to ma­chines, to RAM, to hard disks, to net­work bits and to CPU cy­cles, and so far away from the ac­tu­al peo­ple who have to use their soft­ware, that they au­to­mat­i­cal­ly dis­card every hu­man as­pect when they are faced with an el­e­ment which could be trans­lat­ed into the num­ber of CPU op­er­a­tions, or num­ber of bytes of mem­o­ry. And this is one of the rea­sons soft­ware prod­ucts are so clum­sy and so un­nat­ur­al and un­pleas­ant to use.

When I start­ed to read Alan Coop­er's The in­mates are run­ning the asy­lum, I was in­clined to think that his idea that in­ter­ac­tion de­sign should come first, be­fore de­vel­op­ment, was not ide­al, and that a col­lab­o­ra­tive ap­proach be­tween de­vel­op­ers and in­ter­ac­tion de­sign­ers could make sense. Af­ter think­ing a bit about it, I'm now de­fin­i­tive­ly cer­tain that Alan Coop­er is right. In an en­vi­ron­ment where any de­vel­op­er can claim that the UI should be done this way be­cause some­where, it will re­duce some CPU cy­cles, col­lab­o­ra­tion has no place. If we want our in­ter­faces to re­flect the needs of our users, in­ter­ac­tion de­sign­ers should do their job first, and de­vel­op­ers should not be able to pre­vent them from do­ing it pro­fes­sion­al­ly.