Users matter more than bytes and CPU cycles
There is something completely wrong in developers' nature to be obsessed with performance to the detriment of everything else. It seems even that this compulsive obsession is not something we acquire with practice, since it affects even beginner programmers. For example, a recent now-closed question posted on softwareengineering.SE by a beginner who was asking how to create a website with content written by users included the following paragraph, emphasis mine:
So when I manage to convert user input to html code, how smart is to populate my database with html code? I mean connecting to database every time user opens up website is not very efficient. Should I somehow embed that code directly to html pages?
Unfortunately, this obsession sometimes remains despite years of experience in software development. Now that I think about it, in nearly every case where I heard a colleague talking about performance was when he was encouraging some fancy optimization, without any proof that there is a performance problem in the first place, and that the optimization affects the current bottleneck.
By itself, it is not a huge problem. When developers waste time optimizing some code which wasn't causing any slowness in the first place (or trying to optimize something while making it only slower), the only consequence is the increased cost for the person or the company who pays for the product. Poor overall productivity, extreme number of bugs caused by terrible working conditions, number of features nobody wants, and other major issues have a much higher impact on the cost of software.
Where it becomes a problem, however, is when developers are working against interaction designers under the pretext that they want to do an optimization. A few days ago, I had an argument with one of my colleagues, which is very illustrative of this problem.
I was working on a part of the product which provides a list of entities to the user, and let the user filter this list either by selecting a bunch of criteria, or by typing some text. It was decided, for some superfluous reasons, to keep the list on server side, and do an AJAX request which included the filtering parameters. Following KISS, I decided to launch an AJAX query every time the text field is changed, and see what would happen in terms of performance and responsiveness. What happened is that the app responded well, the AJAX queries being relatively fast. It felt particularly responsive: as soon as the user typed, nearly immediately the list of entries reflected what was typed.
And then one colleague saw this, and found that this is a terrible idea. “Nah, you should use RxJS and pause for a while before launching a request; this is how everybody does that!” he told me. I tried to explain KISS and premature optimization stuff, but there was no use talking to someone absolutely convinced that everybody does that.
The fact that everybody doesn't do that (at least Google Search doesn't) is irrelevant here. What is important is that he intuitively attempted to make the application unresponsive for the users just because he thinks that something should be optimized for some imaginary reason. For him, users shouldn't be taken in consideration, or at least, the users' needs come after CPU cycles. What would happen for the users as a consequence?
The action would look like searching instead of filtering. For a user, search might take time; filtering, however, is immediate. The user doesn't care if the action takes place in the browser or through an AJAX request; if it's filtering, it should be direct.
The interface would look unresponsive. Those timers which launch an AJAX request no more than every 500 ms. were imagined by programmers, from programmers' point of view and for their goals. When I type something, and the app randomly reacts to what I type and occasionally waits for half a second before acknowledging my existence, the application is simply impolite to me.
This attitude which consists of putting bytes over persons is rooted in developers' culture. They are so close to machines, to RAM, to hard disks, to network bits and to CPU cycles, and so far away from the actual people who have to use their software, that they automatically discard every human aspect when they are faced with an element which could be translated into the number of CPU operations, or number of bytes of memory. And this is one of the reasons software products are so clumsy and so unnatural and unpleasant to use.
When I started to read Alan Cooper's The inmates are running the asylum, I was inclined to think that his idea that interaction design should come first, before development, was not ideal, and that a collaborative approach between developers and interaction designers could make sense. After thinking a bit about it, I'm now definitively certain that Alan Cooper is right. In an environment where any developer can claim that the UI should be done this way because somewhere, it will reduce some CPU cycles, collaboration has no place. If we want our interfaces to reflect the needs of our users, interaction designers should do their job first, and developers should not be able to prevent them from doing it professionally.