Infantile Programs

Synopsis: A maturity index for software, ranging from infantile to wise.

Why does software suck? How can users stop feeling inadequate and place the blame squarely on bad software?

Programming languages (and programmers) have been around for at least five decades: FORTRAN, an early high-level programming language, dates from 1954-57. So one would expect the science of programming to have reached maturity by now, and perfectly performing programs to be the norm. After all, one takes perfectly functioning transistor radios for granted today — the first transistor radios came to market in the same period, 1954-57. It is amazing to see that many computer programs are still so annoying to use.

Many blogs and even books have been written about it and I will not add to that. Instead, I present a classification of computer applications, along what could be called a maturity dimension, by which to judge software. My proposal is that, as with us humans, there are certain levels of maturity in a software product: infant, child, teenager, etc. These levels are described below.

Infantile programs need constant attention: These programs expect a doting user to be watching them all the time. They will frequently pop up dialog boxes, either asking stupid questions, or just “Look Ma, no handles” kind of messages. GUI-afflicted programs will, of course, stop dead in their tracks until the user does something.

Infantile programs sleep a lot: Although these programs may have run speedily in the lab, they stumble in the real world – slow networks, locked files, fading network shares – a number of things cause them to just go to sleep, while the user’s adoration turns to anxiety (“John come quick, the baby stopped breathing”).

Infantile programs may barf any time: If they dont get stuck, they will often crash or abort, creating a mess on the disk.  Bottom line is, infantile programs may be cute to look at, but accomplish very little.

Childish Programs

Childish programs need frequent hugs: This is often a side effect of a program that was designed for the developer’s convenience instead of the user’s. Consider a program that needs to process many items. The straight line algorithm processes one item at a time. If every hundredth object hits a snag, the program will stop periodically and ask the user how to proceed. An example is Windows XP file explorer’s file copy function. It pops up dialog boxes about problems such as duplicate files as it happens to encounter them. Don’t leave a large directory copy running overnight: chances are it will be spend most of the night stuck in a dialog box.

Childish programs crawl into places they shouldnt: Favourite places are the registry, with obscure entries that cause mysterious changes in behavior after reinstallation or restart; carelessness with kernel resources such as handles, locks, or memory. Once, I tried swapping the location of my two network cards because the childish program supplied by the internet provider got stuck at the first card it detected when it should have moved on to the second card that connected to the internet. Unfortunately, the operating system did not delete the IP addresses for the old configuration from the registry, and refused to let me put the desired IP addresses in the swapped configuration.

Childish programs poop in wrong places (POOP = Persistent Object Oriented Programming): Temp files that are never deleted, passwords and other secrets in memory that are not secured, log files that grow without bound.

Childish programs won’t clean up: Have you seen programs whose installation README says, “IMPORTANT! please uninstall the previously installed version, otherwise the program may not work correctly”?

Childish programs may scribble all over your office work:  One more reason to take regular backups!

Childish programs must be protected from strangers: Just two words — insecure code.

Childish programs’ baby talk is understood only by the parents:  Amateurish user interface design, unconventional interface styles, ambiguous messages. Although the demos may be impressive, real-life users frequently go bald.

Teenager Programs

Teenager programs are arrogant and impolite: They grab keyboard focus, start in-your-face maximized windows.

Teenager programs are moody: Their behavior fluctuates. Do the expected one day, do something strange the next.

Teenager programs have their rooms in a mess: For example, an ever-growing bunch of files with long numeric filenames.

Teenager programs are disorganized: Mixed-up architecture or design – Some pieces do things in one way, other pieces do similar things in a different way.  Menus are not organized in a standard fashion. Menus items are rearranged in the next release; input validation is inconsistent, etc.

Teenager programs often leave the door unlocked: They may be security risks. Overly fancy algorithms written by kids fresh out of college may hide vulnerabilities.

Teenager programs hog telephone lines: They are greedy with resources like network or memory. Will often freeze the computer when presented with large amounts of input (e.g. an earlier version of MS Word).

Teenager programs are hard to protect from strangers: over-confidence and no fallback plans.

Teenager talk is difficult to understand: This is different from childish talk; teenager talk is deliberately slangy. “A device-specific error occurred”. “This program has performed an illegal operation and will be shut down”. “You have chosen to cancel a background job [Continue][Cancel]”

Adult Programs

Adult programs are dependable and predictable:  they often have transactional semantics, so that they can recover to a consistent point after a crash.
Adult programs are flexible: they can tolerate different circumstances, use alternative methods if usual methods fail; detect and adapt to different environments. An example is a text editor that will adjust automatically to ASCII or UTF, LF or CRLF, or detect which syntax highlighting to use.

Adult programs do not leave bitsam behind: even after a crash or a failed install, the system is in a clean state.

Adult programs are forgiving: They are prepared to undo mistakes committed by the user.

Adult programs use safe and secure practices: they will ask for proper authorization, they don’t need to run with elevated privileges, they use the file system in a secure way, always validate all inputs, etc. A mature database program is a good example.

Adult programs take good care of things entrusted to them: as an extreme example, they may store important data in encrypted form.
Adult programs cooperate with others: especially in an enterprise, applications need to work with other utilities such as backup, event logging servers, or load balancers.

Adult programs can deal with strangers: they can use different protocols as needed. They can export their data in popular formats if they dont save the data in a standard format in the first place.

Adult programs are faithful to old friends: they support datasets from earlier versions, they can talk in older versions of the protocol.

Adult Programs stick around for many years: They can be put in service for many years. They are also backward compatible; i.e. support compatibility with data of earlier versions.

Wise Programs

Wise programs also have all the good traits of adult programs.

Wise programs Understand user needs: Will try to do what the user wants rather than what user asks. An example is google search responding to misspelt input such as ‘bichemstry’- “did you mean to search for ‘biochemistry’? here are top 2 results for biochemistry”.

Wise programs are normally predictable, but even unexpected behavior is often a pleasant surprise: For example, browsers remember the folder where the last item was saved. But this doesnt work when I am browsing on two unrelated topics from two different sites from two browser windows. What a pleasant surprise it would be if the browser guessed accurately, from the site URL, where I wished to save the item.

Wise programs are forward Compatible: Adult programs are backward compatible, but if someone sends you a file in a higher versioned format, you are still forced to upgrade your product to the newer version. A forward-compatible program would use self-describing data formats such that even older versions would be able to work with the data. I don’t have a perfect real-life example, but a virus definition file of year 2009 can be read by Norton anti virus versions that were released a decade earlier as well as by later Symantec Antivirus versions (Symantec owns Norton Antivirus). As another example, the XML language is designed to be forward compatible; new tags can be skipped by programs that don’t know how to deal with them.

Aged Programs

Even good programs grow old. Senior citizen programs are sometimes forced to work past the retirement age, sometimes they disappear on their own. BASIC should only be seen in museums, but there are still grown-ups who haven’t learned a more modern language. On the other hand, when did you last use lynx?

Acknowledgements: Thanks to Navin Kabra for reviewing this post and suggesting addition of Aged Programs.