A 1950 science fiction story by Damon Knight described an alien invasion where communications between the aliens and humans was largely one sided, with the aliens’ intents and purposes not clear, though they provided much advanced technology, seemingly for free. The humans obtained a copy of one of the aliens’ books. The title was translated first, and rendered as “To Serve Man.” The general thought among the humans was that this proved that the aliens were here to help solve the humans’ problems and make a better life, so the alien’s every request was met with approval, including sending many on extended visits to the aliens’ home world–until more of the book was translated, when it became clear that the volume was a cookbook.

And so it is: we have been invaded by an alien species, the computer, that also “serves man.” In the early days of computing, the computer was just “the computer.” A person or team set up a program, prepared
the input, and ran it. Later, when multitasking became popular, along with multiuser systems, and users were connected to it by terminals, the computer itself was referred to as the “mainframe,” as opposed to
the terminal concentrators and the terminals themselves. The term “mainframe” also distinguished large computers that ran an entire organization from “minicomputers,” which were still multitasking and
sometimes even multiuser, but at a departmental or small business scale. Even early networking was among collections of mainframes and minicomputers.

But, the advent of the personal computer changed all that. Early on, personal computers could be connected to a mainframe or a minicomputer by running a “terminal emulator” program, but soon, true networking
came to the desktop computer as well, with larger machines providing shared disk space or memory or processing speed that was not economically feasible to put on every user’s desktop. These more powerful machines were called “servers,” and the machines they served referred to as clients. As desktop machines became more powerful, superficially there was no difference between the client machines and the server machines, so it became fashionable to simply order the same systems, with more memory and disk, and use them as servers. The advent of compute clusters reinforced this thinking. The first clusters were actually built using obsolete client-class machines grouped together to provide processor pools for multiple applications or even to implement parallel processing.

However, relying on machines designed for end-user applications to function as servers is as gross a misinterpretation of the meaning of “to serve” as in the cautionary tale in the first paragraph. “Personal computers” are designed primarily to process business data–word processing, spreadsheets, and presentation graphics, for a single user, optimized for display on the console monitor and input from the keyboard, and some exchange of data over the network. The next step up, what we used to call workstation class machines, are
essentially personal computers optimized for high-quality graphics display and repeated complex calculations requiring lots of memory and/or processing speed and power. Machines designed to play video games are similar, but usually of lower quality components. Mobile computers range from business-class “notebook” and “laptop” versions meant for travel or casual use, down to “netbooks,” machines designed primarily to run web browsers and exchange data to and from the network, similar to thin-client displays found in organizations with large application servers or multi-user systems, little more than a keyboard, display, and network card. All of these are designed to operate in an environment that is comfortable for the user, i.e., 20 degrees Celsius, in a roomy and well-ventilated space, and not produce excessive noise.

With the exception of so-called desk-side servers, true server-class machines are designed to operate in a climate-controlled environment that may not be comfortable for humans for long periods of time–they are usually densely packed in racks, with extra cooling. Their fans run at high speed much of the time, at high noise levels, where the air supply may be uncomfortably cold and at higher velocities and volumes than in human-occupied spaces. The machines themselves are designed to be operated without attached keyboards or monitors, or at least without dedicated console equipment, perhaps sharing one console among eight or more systems. Servers operate unattended, so the ideal machine has internal monitoring sensors and remote console services. A server’s role is to communicate with many clients, so must have high input/output capacity, often with multiple network connections. They must be capable of switching between hundreds of processes a second, and often have much larger processor memory caches than single-user-oriented machines. Because the high cost of high performance is shared among many users and processes, they will have faster memory, more memory capacity, and disk arrays optimized for fail-safe operation, error-correction, and high speed throughput.

If your business requires network-based services, it would be wise to select servers that provide the performance, reliability, and availability required for the specific mission, with room for expansion to meet growing needs over the life of the system, and choose between large symmetric multiprocessor systems and clusters of smaller machines based on the problem to be solved. Using even high-end personal workstations with similar CPU, memory, and disk capacities just may be a mistake, the difference between being served and being the next meal for the competition.

As information technologists, we focus on what the software we write needs to do when we write it. When we finally release it to the user, we’re pretty sure we are familiar with every aspect of it. But, even if we think we wrote it to the user’s specification, there are surprises, some of which remind us of the cognitive tests we took in school, where we are to choose the one that is different, among seemingly unrelated objects.

There’s an old saying that goes, “I’m sure you think you understood what I said, but I’m equally certain that what you heard is not what I meant.” This goes both ways, when dealing with users. Users describe their problem in their own vocabulary, and have a pretty good idea of what they want to see, but usually not a clear idea of how to make the computer do that, which is why they hire us. We have a pretty good idea how to organize data efficiently in the computer and present it, but often, we miss the subtle meanings in what the user asked, if it doesn’t immediately translate into a neat structure.

Often a user will say, “This item, this item, and that item are special. They need to be treated differently from the rest.” So, we dutifully list those items as exceptions and program for them, probably in a lookup table. Later, the user comes back and says, “The special handling isn’t working.”

We look over the requirements, review the code, can’t find anything wrong, so we ask, “Which ones aren’t working?” The user then points to a new piece of data, one we haven’t coded for. Slowly, it dawns on us that the data items the user listed as special aren’t in themselves uniquely special, but belong to a special classification, that perhaps isn’t immediately obvious from the original list. Whether the association is even recognizable may require some in-depth understanding of the user’s knowledge domain, so now we are faced with the problem of fixing the data each time new data is added, or whether we fix the program to recognize the pattern.

But, if we find a pattern, we need to check with the user to find out if that truly is a distinguishing characteristic, or just coincidence. It could be that the user hasn’t noticed that the naming for his special category happens to follow a convention, and the next one might just have a different twist on it, or the pattern you deduced may not be unique to the set of items the user is thinking about. Normally, if data items are to be grouped, there should be a field in the attributes to identify membership in a group, or a separate table if an item can be a member of several groups. However, when imported data must be classified automatically, it is important to clearly identify a unique recognizer pattern, and make sure the user understands the need to be consistent.

So, Microsoft has rushed Windows 7 into production, but that computer you bought just a year or two ago still has all its keycaps and the dust bunnies poking out of the air vents aren’t too thick yet. It’s probably good for another year or two, maybe even five if you clean it now and then. But, it’s got Vista on it. Bummer. And Microsoft isn’t going to apologize for the Vista fiasco and update you for free, are they?

But, there are any number of other companies out there that are willing to do just that: update you for free, to something completely different. Linux. And now is a really good time to switch. Unlike the computer store down the street, where you can buy a variety of shapes, colors, and sizes of computers from many different manufacturers–all with the same, aggravating, slow, and unsafe Microsoft system on them, many different vendors hawk multiple versions (actually, distributions–packaged sets of options) of Linux that will run on the computer you have.

What is Linux? Linux is, like Windows, an operating system, a friendly abstraction that turns the bits and bytes running through your computer into words and pictures that you can work with, and connects you to your printer and the Internet. The difference is, Microsoft wants you (or, more precisely, your computer’s manufacturer) to pay for the “privilege” of using their system. That they own, and keep the inner workings of a closely guarded secret. Which doesn’t provide security for you, since hackers whittle away and find the holes in it. Besides, the original premise of Windows was to provide all of the system to you, the user. Unfortunately, the inner workings of the machine are also laid bare to every program you run and to much of the data that flows into your machine from the Internet.

Linux is, as the Monte Python skit goes, “Something completely different.” Linux is based on Unix, a system designed more than 40 years ago to allow many people to use the same computer at the same time without crashing either the system or seeing data that belongs to someone else. Unix is the system that evolved to create the Internet, retaining that same, solid goal of protecting the system from its own users and any outside data. Linux is also the flagship of Open Source movement, crewed by the Free Software Foundation’s GNU project: all of the pieces of GNU Linux belong to everyone–by definition. Anyone is free to use and even change or add to the code, so that the community of users (many of whom are skilled programmers) contribute to continual improvement and innovation. Want a browser that works better with social networking? No problem. Someone who has an idea how to do that has written one, and one or more of the companies that package Linux for end users has included it in their distribution. Or, if you can’t wait, you can download the source code–the original, human readable (well, geek-readable, anyway) instructions–and build it into your copy of Linux yourself.

So, why would a company (like Red Hat, Novell, or Canonical) give away software? Because they don’t develop it, they just support it, and support is how they make their money. But, it is your choice. If you depend on Linux for your business, a paid support subscription is essential. If you only want to try out Linux, it doesn’t cost you anything except the price of a blank CD and maybe a pizza for the kid down the street to come over and show you how to download, burn, and install it. You can even try Linux from the disk without installing it, so there’s no commitment. After the first installation, you can keep your Linux computer up to date with on-line updates, when you choose to do so. Unlike Windows, Linux always tells you what will be updated, gives you a choice, and then gets out of your way while it performs its job. Rebooting is rarely required after an update.

This month is a good time to think about changing to Linux. Most Linux distributors put out a minor upgrade every six months, and a major upgrade every two years. The most popular distribution for desktop users and home users is Ubuntu, from Canonical. Canonical puts out a version upgrade every six months, in April and October, and a “Long Term Upgrade” version every two years, that will be supported for three years, so you don’t need to upgrade again if you don’t want to. Each version is updated with security fixes and bug fixes as needed, for at least two years after initial release. On April 29, 2010, Ubuntu 10.04 LTS will be released, which promises to be the best desktop system to date.

I’ve used nearly every major Linux distribution made, at one time or another, and currently use Ubuntu on my desktop systems, including my laptop (which originally came with Windows Vista on it, so Microsoft counts it as “one of theirs,” and got paid for it, though it is never used). I will admit I had to do some system administrator tricks the first few versions, but the current version, 9.10, very nearly worked “out of the box.” Ubuntu comes on one CD, which gives basic desktop productivity and Internet access, to which you can add software with a mouse click as you need it. My systems are complete development systems, with web servers, compilers, and many other tools you never need to load if you don’t use them, unlike Windows, that comes with a ton of features few use, and “demo” versions of productivity software that you have to pay extra for if you want to keep using them.

So, keep your old Vista or XP computer, but give Ubuntu a try, next month. If you can’t wait for the sometimes slow downloads that are inevitable after a new release, borrow a disk from a neighbor–it’s perfectly legal, and encouraged–or you can get a disk in the mail from Canonical. You can choose to “demo” Ubuntu without changing your hard disk, running it from the CD, or you can install side-by-side with Windows and start up in either Linux or Windows. You can add the Wine package in Linux and run some Windows programs from inside Linux, and you can still read files from the Windows half of the disk. But, Linux will be invisible to Windows, so you will find yourself booting Windows less and less often, because you can’t live without Linux. Linux computers don’t get malware or viruses, so your files and your system remain safe, but you, the user, are still vulnerable to phishing attacks and phony web sites that steal your on-line identity.

But, if you are still intimidated by installing your own software, and you need a new computer anyway, buy an Apple–it’s Unix, too: it’s not free, because, like Windows, OS/X support is bundled in with the computer when you buy it and when you install a system upgrade, but, because it is Unix, it’s inherently more secure and stable.

On the way back from an outing to the beach yesterday, we passed the cooling towers for the ill-fated WPPSS #3 and #5 nuclear power plants near the village of Satsop. Having recently commented on a book about an ambitious software project, I reflected on a common theme when it comes to discussing software, “Why can’t software be engineered like bridges and power plants?” Well, perhaps it is. Like software projects, civil engineering projects also fail, sometimes spectacularly. Bridges and stadiums fall down, buildings and power plants remain uncompleted eyesores.

The misfortune of the Washington Public Power Supply System, with the unfortunate acronym pronounced “whoops,” is a prime example. Oft-cited references from Seattle newspapers at the time mostly quote the cost overruns and delays as the major cause of the WPPSS default, which we don’t deny. But, other factors certainly had a hand in pushing opinion against completion of the project. One was an inflated estimate of power demand when the projects were initally launched. Public engineering projects, like large software projects, take a long time to build, during which the original requirements may change radically. Rather than spurring demand for alternate energy sources, the 1973 oil crisis was so sudden and deep, that it instead instigated conservation and frugality, reducing overall demand. At the same time, the question of alternate sources brought environmental concerns to the fore, and some of the delays were due to demands for stricter environmental accounting, such as potential impact on salmon and other fisheries of dumping excess heat into the Satsop River, and the fact that two million people lived directly downwind, under the radiation plume in the event of an accidental release. The latter was of concern because part of the delay and cost overrun was due to rework of substandard assemblies. The plant construction was halted, and power customers in the Northwest were faced with a 2.25 billion dollar bond default, a spectacular failure, indeed. Incidently, the only plant in the project to eventually be completed does produce electricity at lower cost than the combined hydro, nuclear, and coal-powered grid, but the failures at Three Mile Island and Chernobyl thoroughly dampened enthusiasm for nuclear power for decades.

How does this relate to software? Well, we can certainly learn from the lessons here:

• Requirements change in unexpected ways
• Poor training and planning results in costly rework
• Failures in operation can be catastrophic to your business
• Small pilot projects can succeed, where large-scale efforts fail

The practice of software engineering has evolved a great deal in the 40-odd years since Edsger Dijkstra called for the evolution of structure in coding practice with his “GOTO Considered Harmful” essay, and, indeed, much changed since my personal epiphany 20 years ago, when I discovered, on enrolling in a formal study of software engineering, that I had apparently spent the previous 20 years in another profession with the same name. Software is not like concrete and steel, that must be planned completely from the beginning and constructed stepwise from beginning to end, with only incidental changes along the way, though the classic “waterfall” software methodology was modeled on the brick-and-mortar construction. A number of methodologies have evolved, including the spiral method, in which the concrete and steel are considered as plastic as the facade and details; and the rapid prototyping method, which is akin to a false-front movie set, where the user interface and operations come first, using off-the-shelf or mock-up back end components, with features that appear automated operated by stage hands behind the scenes. The spiral method essentially uses more frequent inspections, so that mistakes or misunderstandings in the foundation get bulldozed and rebuilt before the frame goes up. Newer methods, like extreme programming, merely address the issue of code verification and validation, organizing programming teams to reduce coding errors and incorrect or omitted implementations of the specifications by using continuous inspection.

A lot of my work falls into a sort of reverse rapid-prototyping mold: the problem gets solved in the back end, which is difficult, but produces a useful result. Often, the project is a one-time run, especially when it is part of a scientific research project. The expensive, time-consuming, but not particularly difficult front end, the user interface, just never gets built. The user gives me a flat file or spreadsheet or maybe just a list of data sources and a description of what is needed back, and I give him or her a spreadsheet or graph with the results. End of project. Some of these “one-off” projects end up becoming research tools valuable for a number of projects, so they get converted from a command-line script into a web CGI application. The point here is that cost is put in where it gets the best bang for the buck–as the requirements evolve. And, as a bonus, when the front-end gets grafted on, I often retain the option of running the program in command-line mode, which greatly simplifies testing and debugging. The prime factor is not necessarily overall cost of the project, but cost per use, that dictates the tradeoff between doing a lot of manual steps (which are part of the design process anyway) and writing a program to do it automatically.

On the other side of the coin are the web site designs, a craft which evolved concurrently with the rise of rapid prototyping as a methodology, and is well-suited to that approach. For these, I design sections of the pages with the layout in CSS and the content management in PHP, for the most part. At issue here is the content itself. I usually start with simple PHP arrays or maybe tab-delimited flat files, especially for sites that change slowly or don’t have a lot of data initially. These have the advantage of being immensely portable, since the data is self-contained. But, for sites where the data is collected from the user, a database is easy enough to drop in, if the data-management functions are sufficiently cohesive. Like the scientific research scripts, I usually like to handle the data updates myself at first, since the hard part to program is data validation. Until you have done a few of these, the number of variations in format the same data can take–that the user considers “the same”–is mind-boggling. Since a lot of my scripts acquire data from files rather than from dialog, it becomes necessary to parse all possible variations and then validate the result, rather than ask the user to re-input the data. Phone-number-handling routines do this all the time, removing parentheses, dashes, white space, and checking for other non-numeric inputs as well as making sure the right number of characters are present, but each custom data format requires its own parser.

This seems like a lot of work, but for a site that is undergoing rapid evolution, due to rapid prototyping and spiral development, putting a lot of effort into coding a user content-management system onto the back end is much more expensive to modify than to have the developer add the data until the site stabilizes. That is, of course, unless the site demands frequent large changes, in which case we design the input part first. When I develop a site with a database component, I code the schema into the application, so that all I have to do when I make major changes during development is to run the script from the command line with a switch to delete the tables and rebuild them with the new schema. This option is not available from the web interface, so the application is protected from accidental erasure of all the data. So, even though software is seemingly constructed by trial and error, the template and methodology are engineered, though not as formally partitioned as in model-view-controller architectures like Ruby On Rails and others.

There is an old saying that you can have it fast, cheap, or good; pick any two. This means, of course, that fast and good isn’t cheap, because everything needs to be done all at once, and any changes or corrections will be more sweeping, therefore more expensive. To get something cheap and good, it won’t be fast, but evolve over time, with functionality added as it is needed, incrementally, so that few large, expensive changes are needed. Given a rapid prototype with a skeleton backend, the developer has a chance to work with the user and refine the requirements, adding code instead of replacing it. Using a canned content management system or a model-view-controller development system can produce a system quickly at low cost, but custom look and feel and innovative or complex functionality won’t be there without a lot more work.

Change orders and redesign are a factor in any engineering project, but software seems especially susceptible, probably because the customer doesn’t see the size and complexity. When we build a house and something comes out suboptimal or just not quite what we expected, we are more likely to live with it than to rip out walls and pour more concrete, because we can see for ourselves what it will cost. But, invariably, the first thing a customer says during the rollout of custom software built for him is, “Gee, that’s great, but now can you make it do [something completely different].” Yes, we can, but sometimes we have to throw away everything and start over: the new functionality may call for a very different architecture. Attempts to graft on the changes will result in a product that is not fast, not cheap, and not good. Rapid prototyping, focus on the core mission (solve a problem, attract customers, etc), and incremental development with some behind-the-scenes work can produce a useful product at a reasonable price, even if parts of it get ripped out or mothballed along the way.