The pointlessness of missing the point

A continual source of puzzlement to me is how people can take a certain idea/concept/methodology/whatnot and complete miss the point, often to such a degree that the disadvantages are kept and the advantages removed—leaving us worse off than without it. Terry Pratchett once discussed this phenomenon with the example of how the British* had taken fast food and entirely removed the “fast” aspect, leaving them with slow fast food… There is also a considerable overlap with “cargo cults”.

*I have spent less than a week in Britain and do not vouch for this being true. However, in an interesting parallel, it is my impression that the German versions of McDonald’s and Burger King have grown a lot slower over the years.

An example that I regularly encounter and that prompted me to write this post:

Alpine, my usual email client*, handles locks on folders in a manner that is contrary to the concept of locking. Specifically, if one instance of the program has opened a folder with a write-lock (which is the default) then a second instance opening the same folder will simply take over the lock… What do the nit-wit authors believe is the purpose of a lock?!? To boot, this operation can take some time, delaying further work—and after the delay I have two instances both in the wrong state..

*Yes, Mutt is probably the better choice, but I never have gotten around to make the switch.

True, in this manner there is still some protection in that concurrent writes will not corrupt the folder; however, this would be better solved with a latch* to begin with.

*Since terminology can vary from context to context: By “latch” I mean a very temporary variation of a lock that is set immediately before an action and released immediately after it; by “lock” a full lock that is set at some time to prevent others from performing a certain operation, possibly hours before an action takes place, and released at later time, possibly hours after an action has taken place—and with no guarantee that an action actually does take place. Alpine uses locks and not latches in this terminology.

What would be the proper way to handle the situation? (Assuming that a peaceful coexistence, e.g. through use of latches, is not possible.) The ideal way is likely to prompt the user whether a lock takeover should be attempted. Next best version would be to simply tell the user that the folder (in the second instance) is in read-only mode because of an existing lock. (For Alpine, the latter must of course be complemented with the ability to manually remove locks, in case of a software crash leaving a lock in existence. In many other cases, say a good DBMS, such locks would be cleaned out automatically.)

At any rate, it is quite clear that the lock should per default remain with the instance that locked the folder. The opposite is like a locked physical door changing its lock and handing out a new key to the next person who pushes down the handle…

Computer/software usability is an ample source of other examples. Consider e.g. w3m, a text-based browser that I often use when logged into a server: Among the problems are that is has several ways to exit. One, the input “Q”, exits unconditionally; another, the input “q”, prompts the user whether w3m should quit or not.*

*Fortunately for me, I almost always want and deliberately use “Q” to begin with, making the danger for me personally small. Others can be less fortunate.

Both individually are fine, but taken together they are a mess: The reason for the prompt is to prevent an accidental exit from the application. However, by keeping both, the gain from the prompt is negated: It is still possible to accidentally exit in a very trivial way. True, “Q” typically involves one key more than “q” (specifically, the “shift” key); however, this difference is negligible in many cases, especially with an experienced typist in automatic mode. To boot, it disappears if caps lock is on, which happens quite often for inexperienced typists. Worse: There is another input, CTRL-q, which is very similar in form and likely to be used often (implication: close the current tab)—consider the risk of going for the one and picking the other (e.g. through a memory lapse).

Correct behavior: Have one single command which either prompts or does not prompt based on a setting.

Alternatively, do it the Vi/Vim way and have different commands that are too different to pose a great risk and to unusual to pose a major danger. For instance, to accidentally mistype “:q!” or “ZZ” is a lot less likely than “Q”—and neither is very likely to be confused with “:q”. (Yes, there is still a risk that an experienced typists simply has a brain fart and inputs e.g. “ZZ” wanting to cause some other action; however, the risk is smaller and it is not possible to cover all eventualities without disproportionate cost.)

A more complex example is provided by Scrum, which is usually implemented in a very “to the letter” manner, without an understanding of “why”. The result is then, for instance, that a meeting is held because Scrum prescribes the meeting—but that the purpose* of the meeting is not fulfilled. Indeed, Scrum is often run in a manner very much like “cargo cults”: Imitate the shape of something and hope that magic happens, even when the shape is the only similarity with the real thing.

*Usually continual improvement through “inspect and adapt”.

Similarly, naive project managers often have no eye on what they should achieve: They hold status meetings that do not communicate the status (or does so in a wasteful manner); they make elaborate spread sheets that have no connection to reality, seemingly for the purpose of having a spread sheet*; they spend hours in MS Project and only produce garbage**; they insist that certain project step be marked as completed to fulfill a time plan when the step is not actually complete***; etc. A telling issue is when a project starts to run behind schedule—and the time spent in meetings is increased as a consequence. More time in meetings means less time available to perform; less performance means that the project falls back even further. Do the benefit from the meetings compensate? Very rarely—most of the time they are empty actions to demonstrate that something is being done.

*Possibly, they do have some real purpose, but then they must focus sufficiently on achieving that purpose. They rarely do…

**There is no point in having an elaborate project plan when it does not help with the execution, controlling, reporting, whatnot of/on the project.

***If the step is there for a reason, then they either should wait until the step is actually complete or make sure that everyone understands that the plan proceeds with the step INcomplete. By marking the step as complete when it is not, they spread misinformation and increase the dangers involved.

Many other examples in many areas can be found.

My advice: When you do something, take the time to occasionally consider why you are doing it, what the actual purpose of the activity is—and whether your current actions actually are helpful towards that purpose. (If you do not know the purpose, you had better find out…)

Advertisement