Worse is Better and It Shows

Photo by picjumbo.com from Pexels

User Interface is a puzzle itself, it looks deceptively simple in finished form. It acts merely as a medium between the user and the device. This correlation doesn’t only apply to software, but it also applies to any device intended to be used by a human being. Be it a stove, a clock watch, A/C Remote they all have an interface of some sort. They convey the information and ways via which a user can make the most of their experience with the said product. The user, can be a child, a mother, the software developer himself, or even a military aircraft operator. In any case, regardless of the subject and its intended duty the Control, Discoverability, Mapping, Feedback, and Constraints should be present and laid out as apparent as possible.

The more amplified the effects of the software the more crucial the burden on the UI. When it is not done right, the effect can be dramatic such as in the case of the passenger plane, the prominent B737 MAX. Utilizing software instead of hardware (fly by wire) makes many of the systems more streamlined. When a software is distributed to the whole fleet, the faulty code and its effects are multiplied and can not be easily fixed on the go. Applying a bug fix may require sacrificing crucial features or functions. A simple miscommunication between the user input and computer interpretation can spell doom.

Worse is Better

Richard P. Gabriel has elegantly coined the term ‘’Worse is better’’ in the context of software, in his book ‘’the UNIX Haters Handbook’’. It expresses that functionality has no direct correlation with software quality. That is of course considering that the ‘software quality’ is a quantifiable constant. The software should be confined to the bare minimum and do not make any distractions. Software that is simple from ground up, often means that users can easily get on board, documentation would not be a nightmare to navigate and the list goes on. The benefits can be reaped without running a handful of risks and sleepless nights.

Challenging the foundations of software development and confining it with archaic draconian measures are thought to be thrown out the door right around the same time with ditching the switchboards. It is now not reserved for a fortunate bunch. Such foundational problems that are once related to low-level code are now dismissed as arbitrary and rightfully so.

Developers do not struggle with their day to day basic interactions with the computer as far as simple tasks are concerned. What’s worrying is that the same, old, ill-advised practices being surfaced again among high-level languages and their users. It is a distress signal that something is off.

Leslie Lamport, the great mind behind TLA+ and an advocate of better education and understanding of software before laying hands on any IDE has put it not so lightly with his quote :

There is a race between the increasing complexity of the systems we build and our ability to develop intellectual tools for understanding their complexity. If the race is won by our tools, then systems will eventually become easier to use and more reliable. If not, they will continue to become harder to use and less reliable for all but a relatively small set of common tasks. Given how hard thinking is, if those intellectual tools are to succeed, they will have to substitute calculation for thought.

Cognitive ergonomics

Humans have a smorgasbord of cognitive highways that are all loaded with crucial information. In order to relay these signals, neural pathways are utilized so you do not have to cognitively make decisions every time you are confronted with the same or similar tasks. Cognitive ergonomics concern having the system and human cognitive limitations to work in harmony and optimize their interactions. It advises systems are designed around the cognitive workload and factoring in the human reliability or lack thereof in some cases. The most notable examples being the cockpit design and related software. For example, a GOMS model is a standardized way to assess the feasibility of your system with regard to human cognitive limitations.

It is suggested that with considering the human cognitive abilities and tendencies all programs should be consistent, correct, and as simple as possible. Feature creep should be avoided at all costs. It is unrealistic trying to visualize all of the various ways in which a system could be used. It is then advised that simplicity is sought for both the implementation and the interface itself.