About Software

To write a good robust software package, that serves the best interests of its users, one must follow certain rules. But to write a commercially suc­cessful software package, which maximizes one's profit, one must follow a very different set of rules.

To write a good robust software package, that serves the best interests of its users, first analyse carefully the task that the package is required to fulfil. The relevant activities of the human users form part of this analysis. From this analysis, con­struct some form of logical model of the method by which the package will fulfil its task. Then iteratively reduce the logical model to its simplest form, excluding any super­fluous functionality, which may have hung over from the manual method­ology trad­itionally used to perform the required task.

Create a Logical Model

There are many established kinds of logical model up on which a software package may be constructed. For most of the projects on which I have worked, the most ap­propriate kind of model has been what's known as the finite-state machine. In each of these cases, the finite-state machine was made to work by receiving and send­ing messages from and to the user. The logical model was thus what is called a message-driven finite-state machine, which is generally referred to more concisely as a finite-message machine or FMM.

Schematic of a generic Message-driven Finite-State Machine or Finite Message Machine (FMM). The logical essence of an FMM is illustrated on the right. It is probably written as a dæmon, starting automatically when the operating system is start­ed, or being started manually by a terminal com­mand. At start-up, it does its initialization proced­ure and then enters its WAIT state. Here it listens on a designated calling port for messages from human users. It responds to only three possible messages: "shut down", "execute Program 1" and "execute Program 2". If told to shut down, it does its shut-down procedure and stops. If told to do either of its two types of task, it runs the appro­priate program and then returns to its WAIT state. Each program, once it has completed the task re­quested by the user, sends a response message. The FMM could be made to invoke a new instance of the appropriate program to handle each arriv­ing message. Alternatively, it could always use the same single instance and queue incoming mess­ages, wait­ing each time for the program to term­inate before dealing with the next message in the queue.

The chosen form of implementation of the logical model will depend not only on the nature of the user task, but also on the type of computer and operating system selected. At this stage, the logical model of the user application must be rigorously documented in such a way that the eventual users will be easily able to understand it. This part takes a lot of skill and patience.

Code-up The Programs

Next, select an appropriate programming language (such as C or Java) and code up the various message-handling programs which make up the package.

For example, each of the FMM's message-handling programs could be written in C in the form of a Unix command. A Unix command is like an imperative sentence written in English. It comprises a subject, verb, possibly a verbal qualification and an object, as formalized in the following table.

user program options argument(s)
rob@neddy edit-customer address-only customer123 "15 Bridge Street..."

The equivalents of the English parts of speech, as they appear in a Unix command are shown on the lower line of the table. In normal circumstances, the identification of the user does not need to be explicitly specified. It is implicit because he is who­ever is signed into the terminal at the time. His identity is shown already by the operating system before the entry prompt. However, for a complete FMM message, which could have come from any one of multiple users, it is necessary to specify the user explicitly, as it is in an English sentence when the subject is not the speak­er. In the example above, the user is a human called "rob" who is currently logged in on a computer whose network name is "neddy". Rob has requested a change to a cust­omer's address details, giving the modified address as part of his request.

If the user be on a different computer from the one hosting the FMM, then the com­mand line message above must be encapsulated within an IP packet in order for it to be passed across the network that links the two computers. The FMM, on receiv­ing the IP packet, would then strip out the internal command message and pass it to the Unix shell to invoke the appropriate message handling procedure (Program 1 or Program 2 in the above example). Of course, the FMM in a real application pack­age would most likely have quite a large number of message-handling programs.

Programming policy

Make your package future-safe. This means that it must be designed to be as un­perturbed as possible by changes that may arbitrarily take place within the under­lying operating system and programming language in which it is written. At some unpredictable time in the future, your program, after a re-compilation, could sud­denly begin to work incorrectly or stop working altogether because functionality in the underlying operating system or linked library has been modified. To avoid this it is necessary to adopt the strict policy of using the minimum necessary functionality of the underlying system and language.

My preferred language is 'C', which is a very stable programming language. Not­withstanding, for any given application, I use only standard link libraries like math­ematics and X-server. I avoid any special-purpose libraries, preferring to write the functionality they would have contributed into my program. This leaves me in total control of all that my program does. And nothing any third party may do can take that total control from me.

As regards minimising the use of the features of a programming language, I once did the illustrative exercise of converting a 3500-line program to avoid using C's struct feature by parsing the data I needed straight from the disc buffer. Although this would have been slow in a bygone age, today it is fast because modern machines have very large buffers. It also resulted in tighter and more intuitive code.

Design The User Interface

Example of an application's graphics user interface. The next stage is to create an electro-physical in­terface through which the human users may send messages to and receive messages from the logi­cal model within the computer. Nowadays, this is normally done by a client-side program, which constructs and operates a graphical user inter­face, an example of which is shown on the left.

In his day-to-day work, the user's focus is on his business: not on your system. For him, the computer and its software are merely a tool. For this reason, the GUI should be to him as transparent, unimposing and self-intuitive as possible. Con­se­qu­ently, when designing the window or frame layout of the GUI, don't indulge your graphic design skills by creating needless eye-catching glitz and fancy unconven­tional widgets. This will serve only to distract the user from his business task, make the GUI more difficult for him to use and slow him down in his work. It will also make the GUI much slower to learn for new users. Keep the design of the GUI as simple and conventional as possible. Make labels and text clear and easy to read. Use only standard widgets: buttons, fields, links, menus and tabs, which users can intuitively recognise.

The human interface does not necessarily have to be graphical. In a lot of cases an old-fashioned text-based interface is more appropriate; being simpler, faster, quick­er to learn and easier to use. Through the interface, the information the user needs to see must be presented in a form that is most easily digestible by the user. This is not necessarily the form in which it is most convenient to retrieve the required in­formation from the logical model.

Schematic depicting dialogue of human interaction with a program. A user probably already knows what he needs to do to fulfil the day-to-day requirements of his job. What he probably does not inherently know is how to do this specifically through the [new] user interface. It is there­fore essential to include, as part of the user interface, procedural instructions for each possible interaction that may take place between the human user, sitting in front of his screen, and the logical model hidden behind it. The procedural instructions should have links to back­ground information to give the user the broader context he will need to fully un­derstand what is going on.

There are many different ways of providing this user documentation. The first is conventional paper books. Another is to write the documentation as a set of inter­linked HTML pages on a CD or hard drive. A rather novel option is to implement the user interface as a Java applet embedded within its own HTML documentation.

My preferred option, however, is to implement the user documentation as a set of context-sensitive help texts. In this case, when the user clicks the HELP button on the screen, a window frame opens in which appears explanatory text pertaining specifically to the step in the program with which he is currently involved. These help texts must be carefully crafted and iteratively improved in the light of difficul­ties experienced by users. The context-sensitive option saves the user having to go and find the information he needs in a book or file reader. For this reason, I think it is the best option for minimising user stress and fatigue.

Typical Implementation

Most software packages nowadays are expected to be able to provide service to users spread over many computers. These may be located not only in different parts of an office or factory, but also in different parts of the country or even the world. The FMM part of the package must therefore run within a central server, while many copies of the user GUI part of the package must run within many differ­ent client computers in different locations.

Below is shown the server computer running the FMM Server Software with just one of the many possible client computers connected to it via a network. The network can be either a local area network or the Internet itself.

Illustration of the client-server model.

The user enters his requests to the FMM through the package's GUI, as shown on the screen in the above diagram. The client software, operating behind the GUI on the user's client computer, converts his request into the form of a command-line, encapsulates it in a network packet, and sends it to the FMM running in the server. The FMM in the server then executes the requested command and returns the re­sults as a message sent back to the client software of the user concerned. The GUI software then displays the results for the user to see on the screen.

A well-designed software package, thus constructed and implemented, should be self-teaching to reasonably self-motivated new users and should rapidly become maintenance-free.

From my experience over the 50 years since I began programming computers, pro­ducing software of this kind, and in this way, will certainly provide you with satis­fied users. But it is definitely not a recipe for commercial success.

Opting For Commercial Success

To write a commercially-successful software package, which maximizes the profit of its producer, one must already have, or be able to acquire, rather a lot of capital. What follows involves initially spending an awful lot of money.

First survey the market. Conduct surveys to find out what the most influential set of potential customers actually want. Be aware that what they want is what they think they need. This is not necessarily — in fact, it rarely is — what is best for them.

The results will be a mess. The surveyed potential customer is not usually an ex­p­ert systems analyst. He will probably have his own cloistered traditional way of do­ing the task concerned, which will have just "grow'd" like Topsy as his business evolved. Consequently, this way (or methodology) is unlikely to be very efficient. It probably contains procedures that "go round the sun to meet the moon". But it is what the customer wants. So it is what the customer must have.

Create an amalgam of the survey results for all the potential customers whom you surveyed. Thus you have a market view of what the task is and how it should be done. The amalgam is guaranteed to be even more of a mess than the singular view of any one of the survey participants. Notwithstanding, you must use this as the basis of the illogical model from which you will construct a software package to fulfil the task concerned for the industry you surveyed.

You now have the specification of a software package, which conforms to the wish­es and desires of the generic customer in the market-sector you surveyed.

The Need For a Glitzy GUI

Now to write the software. Never mind about the underlying functionality that must take place within the server. Begin with the GUI. Design a user interface that dis­plays what the generic customer wants to see and how he wishes it to be pre­sented. This is unlikely to be all the information, and nothing but the information, that he really needs. It probably contains superfluous information he does not really need and lacks other details that would be useful and could even eliminate the need for one or more other displays. But it is what the generic customer has asked for.

Remember that you are building a software package for sale. You therefore need to impress the potential buyer. The buyer is rarely the user. The buyer is who has the money, such as a company executive. The user is generally a lowly employee. You don't need to impress him. The majority of buyers — the generic buyer — is not tech­nically knowledgeable. He can therefore be impressed only by what he can actually see. For this reason, you must make your package's GUI appealing to look at. It must be a graphical work of art, with suave colour gradients, delicately sculp­tured buttons and a (possibly animated) corporate logo, which exudes precision, excel­lence and commercial confidence.

Fancy eye-catching presentation is absolutely essential. It must be forever new and different. Just like a fashion show. This is what the buyer has grown to expect. At software fares and business exhibitions, what else can the ignorant generic buyer go by, as his aching feet tread their way around the endless stands, glancing at the jazzy screen displays through the thick leaves of the ubiquitous rubber plants? Of course, these jazzy displays — with their glowing colours, idyllic images and wrig­gling applets — take forever and a day to load or update. But who cares? He, the buyer, does not have to suffer the daily frustration of their wobbling procrastin­a­tion. That's for the poor user to endure for ever after. He's the one who has to spend his time waiting upon the sluggish GUI, straining his eyes trying to read the merged r's and n's of its immaculately set microscopic type. He's the one who has to play the game of "guess where to click" within the unconventional graphical con­fusion on his screen.

Next, create a menu or tab system within the GUI to accommodate all the actions the generic customer wishes to do in order to manipulate his information in the way he wants. Minimise the use of words [text]. Instead, represent as much as pos­sible using icons: little stylised pictures that represent objects and actions. Finally, get your programmers to rapidly cobble together a server-based handling program for each action. It doesn't matter if it's full of bugs. What is important is to get it out of the door and into the market as quickly as possible. You can straighten out all the problems later through your on-line automatic update facility.

Don't Reinvent The Wheel

For each functional area of your software, try to find your required functionality in the components of standard and freely available third-party libraries. If the 'wheel' already exists, don't waste development time and money reinventing it and writing it as part of your program. Just use what others have already done. After all, this is the principle of re-usable classes for which languages like Java were designed.

The re-use of functions and classes is fine and of great benefit at system level. Notwithstanding, in all my programming experience, I have rarely seen occasion where it would have been advantageous or even practic­able at application level. It is invariably more economical, intuitive and maintainable at application level to write the functionality in-line.

Of course, the technical downside of this is that the 'wheel' that you find in a third-party library isn't necessarily exactly the 'wheel' you need, but it looks as if it will do. Its interface specification tells you what inputs it takes, what it does to those inputs and the outputs it returns to you. But it is over-simplistic and it does not tell you all of what it does or how it does it. The only way you can be sure of all that is to look inside it. But you can't because it is supplied inside an object link library. It may contain bugs or even intentional features you do not know about. It may be­come modified without your knowledge with the result that the next time you re-compile, all hell will break loose.

But this is wonderful. It makes your on-going services indispensable sorting out the mess. You're the good guy, right?

Pamper Your Customers

Make things easy for yourself and your customers, irrespective of the vulnerabilities to which it exposes their private and corporate data.

  1. Add superfluous functionality to your products to satisfy your customers' every request and desire.

  2. Give them products that connect 'seamlessly' across the Internet so that teams can work in conjunction with members distributed all over the planet.

  3. Build automatic updating soft­ware into your products so that bugs can be fixed and features added without hav­ing to physically attend anybody's actual computer.

  4. If you are maintaining server software, do it across the Internet by 'secure' remote shell commands given in the server's configuration meta language. This way, you don't have to leave your seat or disturb your client with physical visits.

  5. Better still, save your customers the trouble of maintaining software and protecting data in-house by encouraging them to use only 'light client' PCs, divesting all heavyweight software functionality and data storage onto your gigantic cloud service where it is 'safer'.

Now you've got them where you want them. Lock them in, baby!

Let in The Hackers

These 5 carefully crafted measures should give the hackers a good chance to get in there. After all, it only takes one compromised employee to cough up a password to gain them access to a corporation client's computing facilities, be they in house or in your cloud. This opens up many opportunities for hackers.

  1. They could exploit a careless piece of superfluous added functionality to corrupt, steal or lock up your customer's data.

  2. One could enter as a hidden member of a trans-global team to observe what the team is doing and steal information.

  3. They could compromise the automatic update facility by acquiring the key from a disgruntled employee to implant Trojans, viruses and spyware into your customer's computers or cloud area.

  4. They could reconfigure your customers' web servers or your cloud server using the server software's configuration meta language over a secure shell in order to steal, delete or lock up your customer's data in a ransom attack.

  5. Your government could demand that you lock up a foreign customer's data and withdraw cloud services as a means of applying sanctions against a foreign customer, who could be an individual, corporation, bank or govern­ment. Frightening?

But this is exactly what you want. It generates unlimited work for you and keeps you in business forever.

The Training Gravy Train

Unfortunately, what action appears in which menu or sub-menu depends on the methodology that evolved within the generic business of the generic customer with­in the industry concerned. Be aware, however, that no one real customer is the generic customer. Each user will be accustomed to doing things somewhat differ­ently. So no real user will be familiar with doing things the generic way.

Furthermore, the generic methodology will inevitably be rather a jumbled mixture that is anything but logically optimised. Consequently, no user will be able to work out how to use the GUI simply through common sense. He will have to be specif­ically taught how to use the GUI, learning by rote what to do in each situation. The copious use of icons adds the necessity for the user to be taught an entirely new over-simplistic grammarless non-intuitive sub-language for each application, which adds to the amount of training required.

To be the producer of a commercially-successful software package, this is just what you want: a package whose GUI looks like an over-dressed Christmas tree, which is distracting and difficult to get the hang of. Why? because it creates a grand busi­ness opportunity to sell training to customers who, having bought your package, cannot use it without training.

The Consumer Market

With the advent of tablet computers and the smartphone, with their extremely small screens, the GUI has had to be made ever more simplified and compact. This has driven the tendency towards all-icon GUIs.

Icons constitute a sub-language that is separate and distinct from a natural spoken and written language. Icons are not standardised. What an icon means depends on its context. Different software has its own set of icons. Hence, a user has to learn what each icon means within each different application program. Consequently, al­though an iconic sub-language may appear simple to look at, it has to be separ­ately learned.

Icons are easy for pre-school children to grasp. Indeed, as I understand it, they were created within the context of the way pre-reading age children think. As a result, their scope is very limited. But, as St. Paul said in 1 Corinthians 13.11:

When I was a child, I spake as a child, I understood as a child, I thought as a child: but when I became a man, I put away childish things.

The thinking processes of adults are very different from those of pre-reading age children. Icons do not serve well in complex tasks, and if made to do so, become acceleratingly cumbersome.

GUI users are thereby becoming increasingly forced to do things the way a pre-reading age child would. It is like the television sound bite and the small-block newspaper ad. It reduces the adult's attention span and scope of thought to those of a child. It thereby erodes one's ability and propensity to think as an adult.

Whether intentional or otherwise, the way in which the graphics user interface has developed, especially for small personal devices, has tranquillised the adult mind, focussing it onto banality and away from serious thought. Hence the endless truck-loads of trivia that traverse the Internet daily via email and social media. Perhaps this is what the powers that be want: a doped, placid — and hence easily controlled — populace.

Advertise, Advertise, Advertise

All the while, pour loads of your initial capital into advertising your software as be­ing "easy to use". Don't worry. Since your software is destined to dominate the mar­ket, it will be the only software that most will ever see, and the stupid consumer will never be any the wiser.

Place a lot of your advertising in newspapers and specialised industry magazines, thereby obligating their respective journalists to write glowing reports in articles that endorse your software, while issuing unfounded warnings to the hapless buyer against purchasing the products of "unknown" small-fry.

Now you are well on your way to dominating the software market. However, by taking a few dubious extra steps, you can make your position in the market pretty well invincible, while, at the same time, creating further opportunities that will en­able you to really rake in the money.

The Virus And The Trojan

Covertly commission various renegade software experts to create programs known as viruses and Trojan horses. These are programs which, by installing them­selves secretly within people's computers, can cause them to run painfully slowly and per­haps even corrupt or destroy people's personal data files. Creating these programs requires considerable technical knowledge, skills and resources, so it is necessary to bankroll their creators. However, to avoid any suspicion, spread the illusion am­ong the general public that these programs are easily-written nuisances cobbled to­gether by rebel hackers and schoolboy pranksters.

Again covertly, distribute these viruses and Trojans throughout the Internet. This is best done by coming to some arrangement with the operators of certain web sites, which contain active procedures that will download the viruses and Trojans auto­matically into a person's computer whenever that person visits the site. The safest kind of website to use for this task is the porn site. This will greatly discourage people from trying to track where the virus or Trojan came from because the victims will not want to admit to accessing sites for the purpose of viewing dirty pictures.

You have successfully created a real and present fear within the market. The mar­ket needs a saviour. And whoever would be the saviour shall, in the execution of his act of salvation, stand to make a lot of money. You therefore commission somebody to write what shall become known as anti-virus software, whose task is to hunt down and destroy any and all viruses and Trojans that may be infecting a person's computer. To avoid any suspicion of collusion, you and the anti-virus soft­ware prod­ucer agree that he shall present himself to the public as a completely independent business interest. Driven by the fear of losing personal data, and frust­rated by slug­gish computer performance, the public rushes out to buy the anti-virus software.

In the meantime, keep your renegade software experts working hell for leather to keep producing better and ever different viruses and Trojans to continually circum­vent and thwart the defences provided by the anti-virus software. Likewise, the anti-virus producer keeps producing and selling a continuous stream of updates to com­bat the ever-mutating viruses and constantly evolving Trojans. So the wheel turns. And the money keeps rolling in.

Lock Out The Small-Fry

Next, completely lock out of the market all but yourself and other members of the global clique of the big software corporations. Make sure that the dedicated hard-working highly-skilled independent software artisans, the world over, never get a look-in. Do this by popping up a warning message whenever a person tries to install any "unknown" software from any "unknown" supplier, implying that the software concerned could be "malware".

Malware is a derogatory catch-all term that includes viruses, Trojans, and all other soft­ware that is presumed, without basis, to be potentially harmful to people's com­p­uters. It also includes "spyware": a legitimate looking application program, which contains extra undeclared functionality. Such functionality could, for instance, read a person's private files on his hard drive, surreptitiously passing any information of interest to an unknown remote third party across the Internet.

The warning message pops up whenever a person tries to install any software whose producer has not paid the high price for having his software certified, by the global clique, in order to obtain a digital certificate, which would allow it to be in­stalled without the warning message appearing.

The Beckoning Back Door

Now for your pièce de résistance. To keep your quick out-of-the-door bug-ridden software working acceptably well, you need to be able to update it very regularly. Whether your software be an application package or an operating system, you need an automatic update facility. This works behind the scenes on each user's computer. The user is generally unaware of when it is operating or what it is doing. To be able to work, however, it needs full administrator access to all resources with­in the user's computer. It must therefore be able to read and write to any part of the user's hard drive.

This presents you with rather a tempting and potentially rewarding opportunity. You build, into your automatic update facility, a back door to every user's computer. Through this back door, you access any and all the personal information the user has stored on his hard drive. And you do this without him ever being aware of what you are doing, or that you are doing anything at all. From this personal information, you construct a consumer profile of each user. You then sell a vast number of these profiles, for an extremely good price, to commercial interests who subsequently use them to target people more precisely with their product advertising and promo­tions. This is probably your greatest money-spinner: the one thing that positively guaran­tees your commercial success.

But there is a far more sinister use to which this back door may be put. It can be used by government agencies to expedite the most invasive, yet completely steal­thy, form of spying upon any chosen individual. A legal instrument could be issued, forcing you to give them access to the world's back doors. Criminals too, if they could compromise one of your relevant employees, could also gain access to any and everybody's back door. That should make everybody feel uncomfortable. Not that he may have done anything wrong. Personal information on one's hard drive, when taken out of context, can easily be misinterpreted and misunderstood.

As well as having an operating system, a personal computer has many application programs installed, each with its own automatic update facility running in the back­ground. This potentially provides as many different vendors with as many back doors into the user's personal files. The opportunity is there. It is so easy to imple­ment. It can operate unseen. Nobody will know. Is it therefore realistic to suppose that all software producers would, through moral virtue, wilfully refrain from engag­ing in such skulduggery?


So, how can the poor lowly user be protected? How can he gain real security? The only solution, in my opinion, is open-source software. With open-source operating systems and application programs, any one of millions of independent program­mers, all over the world, can examine whichever part of an operating system or application program he wishes and thereby know exactly what it is doing.

Of these millions, there will always be somebody who decides to get his claws into every last piece of code and who will blow his worldwide whistle on any program that is doing something against the best interests of its users.

© Feb 2014, May 2017 Robert John Morton
Related article: Who Owns Cyberspace?