I hadn’t thought that much about the ‘controlling the real world’ issue because so many of my projects during the first four years after I graduated from college were just that: software that controlled real-world objects. These included: an oscillation-dampening system using a hybrid analog/digital computer (proof of concept for large-space structures); the Space Shuttle Flight Simulators at NASA/JSC; an HP graphics terminal emulator to drive a large-bed (6′) Houston Instruments plotter; and embedded software for various data acquisition devices. So I just take such things for granted. ..bruce..

But I would like to add one more serious issue which tends to arise, perhaps because of the very nature of the IT business. That is the tendency of software teams to live in “data world” where everything is in computer memory, and real things have lost their existence. That is perhaps understandable enough for a web application, and in our modern times even for financial systems which in the end most often do deal with numbers in computer memory. It gets rather more troublesome when applications do have to interact with objects in the real world. Symptomatic for this is that the software developers have only ever seen their own office, the IT manager’s office, and of course all the meeting rooms; but never the work floor, production plant or laboratories. They have identifiers for things and devices in their systems, but they can’t image what the actual objects look like. As if one would try to write the system software for a car assembly plant, without knowing what a car is. It does happen. And it makes it almost impossible to arrive at a “baseline specification”.