Police State Languages, and Businesses

In George Orwell's "1984" the totalitarian state government has created a new language, one based on ordinary English, called Newspeak. They are just beginning to introduce it to the population in the time period in which the novel's story takes place. It is not an optional language; it is positioned to become the state's official language and, over perhaps a generation, it will be the only language to be spoken.

Newspeak, as Orwell describes it, complete with examples, is restricted in both form and vocabulary. It is designed to make it difficult to say things which the state deems to be bad, and conversely making it easy to say the things of which they are likely to approve. Further, since we think in language, people will supposedly find it difficult to have thoughts that are contrary to the state's interests. If successful, the change in language would solidify the state's control over its citizens' minds and lives.

Despite some problems with the realization of such an outrageous idea, it is one that is a common topic in software engineering. Computer languages are strictly formal, with syntax and often semantics firmly based on propositional logic, with any deviation causing errors. Those errors must be corrected for a program to run. This fact makes computer language design quite similar to Orwell's Newspeak. One of the key questions a language designer must consider is whether to accommodate software designers' whims or creativity, or tie the structure down in a way that compels them to design software that meets the language designer's objectives.

This concept was first forcefully introduced to me by Robert Dewar, one of the creators of the Spitbol programming language (a version of Snobol) during a seminar he gave when he visited my university. With a nod to Orwell, he called computer languages that forced programmers to avoid a wide range of common, if sloppy practices as police state languages. The distinction is that in police state languages (which Spitbol most definitely was not) the objective was to make it difficult for the programmer to write "bad" software. Not impossible, just difficult, so that there was a greater likelihood that "good" software would be written.  Modern object oriented languages such as Java can be classified as police state languages since they rigourously enforce a data structure and flow of control that is inconvenient (and often pointless) to avoid.

Conversely, non-police state languages make it easy to write "good" programs and "bad" programs; it's up to the designer to make appropriate choices. Languages such as C are in this category. However, the dividing line between these police state languages and others is fuzzy, and the differences are sometimes subtle.

Beyond philosophical differences there are other advantages and disadvantages to both categories of computer languages that I won't get into here. Suffice it to say that most software designers use both at different times for different purposes.

There are ample analogous situations that can be found in all aspects of human endeavour. A bureaucratic company, and especially the civil services, is rife with police state modes of operation. It seems that the most trivial task requires the filling out of forms, the request for approval from one's manager (who may then seek the same from his or her manager), documenting how every hour of every day is spent, and so forth. These are organizations that make it very difficult to do bad things. They also suck the life out of their employees by destroying creativity, initiative and productivity.

Presumably these organizations are perfectly satisfied with the trade-off. Private sector organizations of this type (think of insurance companies and even, though to a lesser extent, the old Nortel) are vulnerable to competition or a rapid evolution in their markets.

Entrepreneurial companies that are aggressively growing are of the other category. These companies harness the energies of their employees in ways that are a joy to see and experience (everyone ought to have this opportunity at least once in their careers). A couple of local (to Ottawa) examples with which I am familiar were Mitel circa 1980 and Newbridge in its first decade. On the down side there is often total chaos, including frequent changes in direction, such as the trashing of one nascent product or market for something supposedly better or more promising, and no sense that the organization is able to function as a unified entity. The resulting inefficiencies are in one sense horrifying, except that the energies released can still result in prodigious results.

These non-police state businesses make it easy to do both good things and bad things, and there is a lot of individual discretion given to employees to make that choice. It is common in these companies to find few formal processes (just find someone with formal authority to sign a purchase order, as an example), nothing that could be properly called a budget, and often products that get shipped have surprising features that were never specified in advance.

As with computer languages there are market sectors that favour each category of business. Oftentimes a formerly free-wheeling organization will, when times get tough, adopt many of the practices of police state companies. Regrettably we rarely see companies move in the opposite direction, away from police-state practices. Instead they tend to die off.

For a manager in a free-wheeling company, it can be very challenging to maintain any sort of control over delivering to objectives. There is often the desire to institute controls. If you are ever in this situation I suggest avoid the easy out -- creating controls that prohibit bad behaviour -- and instead learn to better direct and maintain the team's energy level -- encourage and reward good behaviour. People aren't computers and trying to police behaviour to too great a degree, even with laudable objectives, is rarely the right choice. Leave police-state languages and practices to the computer language practitioners.