I’ve written about this before:

Software people often talk in terms of ‘systems’, using the dictionary definition of the term as a complex collection of interacting parts. But they usually understand the term to be limited to the machines themselves, and the programs which execute on those machines. But the system also includes the people who use these facilities, those who operate and maintain it, their training and job conditions, the support staffs, even the manuals and the librarians who take care of ordering new ones. This system is extremely complex, and therefore, prone to failure. It makes no difference that you have a suitable routine to solve a particular problem if the new guy you’ve hired doesn’t know where to look it up. It takes a long time to learn the intricacies of how a system is implemented, even if it’s just the small part you are tasked to work on, and by the time you start getting good at it the technology changes and the system is replaced by something ‘better’. Before long, even the most experienced staff is busy playing catch-up and no one really knows exactly how the damn thing works. This arrangement tends to favor the individual who learns
quickly but superficially, who is satisfied with short-term results, not long term understanding.

An example: NASA has launched many spacecraft to explore distant points in the solar system, and software plays a key role in how these robot spaceships work. But it takes years to get a space probe operational, political and funding delays as well as long development times usually mean that by the time the spacecraft is launched the computers aboard are obsolete. Add to this the length of the voyage itself, which may take years, and by the time the craft gets to where it’s going the software systems on board are positively archaic. In spite of this, the operators of these spacecraft have proven themselves to be extremely clever at squeezing totally unexpected performance from these systems, working around catastrophic malfunctions, often remotely under very difficult conditions. This has been possible because mission staffs are devoted to the mission, not the technology, they have risked their careers by learning everything there is to know about a now-obsolete system. And they have had the time to learn to get good at it. This is not the mind set encouraged by the working environment of most technologists, where experts on old systems are considered fossils or Luddites. The result is that for the most part, programmers and system engineers do not know what they are doing, everyone is working in the dark, by intuition. We use only a tiny portion of the capability of our equipment, and we cover up our failure to utilize it fully by constantly demanding even more capability. The situation is not quite as bad in hardware, where it takes time and effort to move a concept from the engineer’s mind to the marketplace, after all, there are all those factories and machine tools which have to be mobilized. But in software a fundamental change can be typed into a keyboard in the morning and out to the users in an afternoon email. This is why computer hardware is so reliable and computer software is so prone to failure. Putting it another way, we couldn’t afford to build the Panama Canal today, the software costs would be too high.

So I sprint now just to keep up. I’ll keep doing so until an uncaring and unkind industry grinds me into a pile of dust (probably by middle of next week or so).

Consider aircraft and their pilots. The first planes were directly controlled by human intervention, information acquisition was through human sensory input and feedback, servo power was provided by human muscle. When you flew a cloth and wood biplane by the seat of your pants you used eyes, ears, sense of balance and spatial orientation and you pushed on the stick, throttle and pedals. Commands were transferred to control surfaces by rods and cables.You could FEEL when your ship was about to stall, or when the engine was running too rich or too lean.

Then we added hydraulic assists and servo motors to transfer our motion and strength to the machine. Instrumentation replaced flying by the seat of your pants, even the stall announced itself ahead of time with a buzzer. We were trained to ignore our senses and trust our instruments.

In today’s fly-by-wire aircraft you don’t fly at all, you tell a computer what you want the plane to do and it tells the aircraft what it needs to do to itself to execute that maneuver. Sure, you still have a stick and rudder, but they are only a user interface designed to be familiar to a pilot trained on an analog aircraft. You could just as easily fly using a mouse and keyboard.

Kids are good at learning languages, and they are quick to take advantage of the new capabilities of digital systems. When I learned to program in ’64 most of my undergraduate lab work involved coding up algebraic equations for older PhDs who didn’t know how, or who had taken the courses but still weren’t comfortable doing numerical analysis with Fortran. Even those who knew how didn’t feel comfortable with it; it seemed alien and cumbersome. But they needed the speed and the ability to process large datasets. Calculating a model of a stellar interior used to be a year long project for an astrophysicist, people used them as graduate theses. Now an undergraduate assistant, given the equations, could code it up in a few days, and the program could execute in a few minutes (even if the computer center had a 24 hour turnaround time!) And once the program was written and debugged and tested, you could change the parameters and run it several times a day to see how the results would vary.

Yeah, I used to be pretty arrogant about the old-timers too, how they had to come to me now just to publish bread and butter papers. But as I grew older I soon learned to sing the blues myself. I quickly fell into the tech trap, the more capable the technology became, the larger a proportion of our effort went into managing, maintaining and applying it. You spent less time on the job and more and more time debugging your tools, and more dependent on them even on doing the most routine tasks. You see, you now no longer get handed the equations to solve a physical system, now you have to worry about user interfaces, file structures, down line processing. As a mapmaker later in life I spent very little time using GIS to draw maps, I spent most of my time learning new software, new file formats, interfacing with other systems–in other words, overhead.

And the new kids coming out of school seemed to understand all that stuff so well, even if they couldn’t tell the diff between lat and lon, or know what a map scale was and how to calculate it. Now I was the old-timer.

And you can count on one day have it happening to you, too.