While my family and I were at a restaurant waiting for our food, my sister talked about a potential temporary job that would involve data entry to convert records from one database system to another (possibly along with other activities). I immediately thought that this was the kind of thing that should be handled with a little programming, not tedious and error-prone data entry. I said as much, and her response was twofold. First, she pointed out that the data-entry job would involve error checking against paper records. I didn't respond to this, but it seems to me that there would still be value in automating the actual data entry even if manual error checking remains. However, she also speculated that the company might be able to pay less for this one-time data-entry job than for a programmer to write a conversion program. We don't have enough information about this particular job to say anything definite about this, but I pointed out that the conversion program might be very simple and quick to write, possibly reducing the necessary work by several orders of magnitude. She acknowledged this, and we agreed that we won't know if this job can be automated until she interviews. But this conversation got me wondering if most non-technologists truly understand the labor-saving potential of computers, and if so, what attitude they have toward it.
This wasn't the first conversation in which I brought up the labor-saving potential of computers. My sample size may be too small, but judging by conversations I've had with my conservative middle-class American family, it seems to me that non-technologists don't think much about how much tedious work could be saved by programming computers to do more of it. Assuming my perception is accurate, why is this so? More importantly, what can we programmers and other tech-savvy types do about it?
One obvious hypothesis is that most people don't think about the possibility of saving labor through programming because they have only ever been exposed to closed, inscrutable, proprietary software. Indeed, in the situation I discussed at the outset, the old database system and/or the new one might be proprietary, which would make automated migration more difficult. The increased difficulty might be enough that manual data entry really would be better in this case. But even merely perceived opacity is probably enough to ensure that the decision-makers won't think about the potential for automation. Sticking with the database migration example, suppose that under the hood, the old system was based on the Microsoft Jet embedded database engine, and the new one is based on SQLite. (I choose these examples because neither is prominently visible to a typical user, unlike, say, MySQL or MS SQL Server.) I could probably figure out the schemas of both systems and write a conversion script. But it would not occur to anyone with decision-making power that this is feasible, because as far as they are aware, both systems are sealed, opaque boxes. But if more business applications were free software, and the implications of software freedom were well understood, then perhaps more business owners and managers would realize the full potential to automate straightforward tasks through programming.
Another possibility is that people associate programming exclusively with large, multi-developer, months-long software projects. Of course, some programming languages, tools, and processes are designed with this kind of thing in mind, and one might argue that some even encourage it. Michael O. Church's essay "Java Shop Politics" springs to mind. In this light, I consider it fortunate that languages which lend themselves to small, succinct, quickly-written programs are in vogue now. Some of these languages may be deficient for programming in the large, but that just means that programmers and managers alike need to avoid the trap of wanting one language to rule them all.
Another potential reason why people don't think about the full potential to save labor through programming is that they might think of programming as a highly specialized, maybe even elitist, profession with a high barrier to entry. I dare say that some programming ought to be this way, such as development of safety-critical software, and even development of mass-market commercial software. But a high barrier to entry, whether real or merely perceived, may prevent people from thinking of programming as a way to eliminate some gruntwork. It really doesn't help when we programmers look down our noses at certain languages, such as Visual Basic, as declasse or only fit for those loser wanna-be programmers. Whatever we may think of such languages, we have to admit that they have been useful in lowering the barrier to entry for many programmers, thus enabling many more useful programs to be written. (I confess some disdain for PHP, which I justify by pointing out the security vulnerabilities that are common in PHP code.) Luckily, these days, we can promote languages that are easy to learn and are good for quick, one-off programs, but don't encourage practices that lead to low-quality or unmaintainable software.
But what if more people did understand the full potential of computers to eliminate certain kinds of straightforward, tedious, repetitive work? Would they actually welcome this? I can only speculate. But here in the US, we're recovering from an economical recession (or so I'm told; I haven't experienced any effects of this myself). During the most recent election season here, there was a lot of talk about the need to create more jobs. If more people understood the full labor-saving potential of computers, then mightn't many short-sighted people (and the politicians who pander to them) demand that we somehow put a stop to this job-destroying technological advancement? I'm reminded of Stanislav Datskovskiy's essay "Roman Lisp". Might it actually be a good thing that social networks, content consumption, and other consumer-oriented fluff are distracting people from the true potential of computers?
I have no answers, only questions and speculation.