Stardate 20020728.1258

(Captain's log): There isn't just one kind of software. There are dozens. There are radically different business segments which use software, and they have different needs, different requirements. To try to apply a single concept to them all is at best futile. What follows is a list of a few of the major market segments where a great deal of software is developed.

During most of my career, I developed what is now known as embedded software. The essential characteristic of embedded software is that it is developed in tandem with customized proprietary hardware and its function is intimately associated with that hardware. The software, electronics and often mechanical design is a single overall solution to a specific problem that none of them alone could have solved, and they are designed collectively and simultaneously.

The vast majority of embedded solutions are small, and run on very basic and very slow processors, primarily because such processors are cheap, small and low power. In many cases the processor isn't even a discrete chip, but rather is a licensed core incorporated into an application-specific integrated circuit (ASIC). There's good reason to believe that the majority of sales of embedded software involves ASICs, given that far more ARMs are sold each year than all other 32-bit processors combined, and ARM doesn't actually sell chips. The only thing they do is to license their core to others, nearly all of which produce ASICs. My former employer Qualcomm, alone, sells nearly as many ARMs every year as Intel sells x86's.

But embedded solutions can be immense. The range is huge, and some embedded efforts can involve thousands of programmers; the most obvious example of that being the nameless faceless gnomes who labor away on the code which runs the phone system.

Sometimes embedded software is trivial in use, such as the chip built into a greeting card which plays "Happy Birthday" when you open the card up. However, a lot of embedded software is very critical, and failure of it can cost lives. Embedded software is used heavily in modern aircraft, and in a great deal of medical equipment. If the software in a heart monitor crashes in the Intensive Care ward, the patient might die without anyone noticing. If the flight-control software in a jet crashes, so will the jet.

Developers of embedded software usually require very large amounts of specialized knowledge about the market, the problem and the current design. They need to communicate heavily with the electrical engineers and mechanical engineers who are producing other aspects of the system, and the programmers may need to be specialists in various things. For instance, I used to work on robotics, and the microprocessor directly controlled movement of the arm. Motion control of heavy objects is exceedingly difficult, it turns out; do it wrong and you get overshoots or shuddering or any of several other unacceptable kinds of behavior. You can kill someone that way. One of our robots was powerful enough to impale someone if it malfunctioned.

Timely delivery of embedded software is extremely important. Products are usually planned for a market window, and a lot of planning for the process of ramping up manufacturing goes on during the engineering process. A product which ships seriously late may not sell as well, and a lot of investment in manufacturing may have to be duplicated at huge expense. General Motors, for example, cannot delay manufacturing of a new car because the software for the processor which runs the dashboard isn't done. It will be done on time, and General Motors will do whatever it takes to make sure it's done on time.

In many markets secrecy is critical. Given that two products which essentially the same manufacturing cost may be viewed by customers as radically different in value based solely on the software features which are included, then if you think you've come up with a killer feature it's important not to let your competitor know about it, for fear that he could incorporate it into his product which is intended to ship at about the same time.

The final characteristic of embedded software which is important for this discussion is that it cannot really be debugged except on custom hardware. Some debugging can take place on the desktop and some in simulators, but the real debugging takes a prototype and often huge amounts of equipment. At Qualcomm, our lab contained enough cellular infrastructure to cover a moderate sized city, equipment worth tens of millions of dollars. We sometimes used customized test boxes from Hewlett Packard which cost $50,000 each. Each debug station, fully rigged out, cost in excess of $100,000 not counting the other equipment in the lab.

I go into such detail about embedded software partly because it's my own field, and partly because it's bigger than most people realize. One estimate I saw was that about one third of all programmers employed in the US work on embedded software of one kind or another.

Another area is what's known as vertical apps. These are solutions created for specific customers to satisfy specific needs. The majority of them are created for the customer under contract and belong to the customer afterwards. Sometimes they're highly interactive, and in such cases the vast majority of the users will be non-technical. Some are small, some are huge. Sometimes they are implemented by adapting or customizing standard packages, while others may have to be implemented from scratch.

A good example of a vertical app is