Technologically minded people tend to look for technological solutions to the problems they face. Naturally so, but every technological solution can be improved. There is always another solution, simpler and better than the current one. Most inventors will admit that they know a lot of ways to improve on their solutions – an optimization here a redesign there, etc. The solutions in use are comprimises between the optimal and the practical. Necessarily so, to keep down cost.

But the improvements the designers know about are usually still within the framework originally proposed by the inventor. He or she is too involved in the work to be able to see the big picture and think of a radically new way of attacking the problem. One often overlooked solution: Use people instead of a complex technological solution.

For every expensive man-month you spend in engineering, you could pay someone to do manual labor instead. In software engineering you could often pay a blue collar worker’s salaries for 3-4 months for a single month spent on software engineering. The number obviously varies depending on how specialized the task you need to perform is and how challenging the engineering problem. This factor could easily go as high as 10-20 in the extremes.

Now I’m not saying that you will find someone that will replace most of the software you use. It will be hard to find anyone to replace your Excel or Photoshop, but much of software – and often at the “cutting edge” (has this phrase been cooling of long enough to be used again?) of development – is specialized software aimed at solving very specific and often human problems.

I think this can best be explained with an example: I was once asked to advice on the design of an application for mobile phones. I can’t say what it was exactly (confidentiality clause), but let’s say it was a mobile interface to a personal calendar, as that would face very much the same problems as we did in the project in question. Such a calendar interface would have to be extremely efficient, user friendly and require as little specific know-how as possible.

We quickly ruled out any mobile data interface (text messaging, WAP or other browser enabled solutions) because of usability issues, immature technologies, low market penetration of supporting devices and a long list of other reasons. Voice seemed to be the solution. People would call a number, read aloud their calendar entry and hang up. The entry would then be automatically entered into a centrally hosted calendar that could in turn be synchronized with the calendar on your desktop computer, PDA or anything else. A really handy service for people on the move and obviously most people can’t afford having a secretary.

We did some research and concluded that with the current state of voice recognition software, we would be able to automatically resolve 75% of the incoming calls; 15% on top of that would be resolved with about 90% certainty; and the remaining 10% with less certainty or even require additional info from the user (say the user e.g. forgot to mention the date for a meeting). This may sound ok, but the conclusion was that this would not be acceptable. Only close to 100% accuracy when humanly possible would suffice.

“Humanly” turned out to be a keyword. By designing the system in such a way that the 75% would be automatically handled while the other 25% would be directed to a human operator for confirmation or for a more advanced decision on what to do. In most cases that would be as simple as clicking an “approve” button after comparing what was said to the computer’s suggestion.

Using this kind of a mixed human/software solution, we had reached the same level of accuracy as with a human operator taking all the calls, while minimizing the work. As a delay in the update of the centralized diary of up to 30 minutes was deemed acceptable, the system could “buffer” incoming calls to meet peak load. An average call to the service would be about 15 seconds and a resolution of a mis-interpreted message would take on average 40 seconds. This allows the system to take care of as many as 600 diary entries per hour per active operator. In the scenario originally envisioned – a fully automated one – the system would not have been acceptable at all and a human only (yet with the buffer) approach would have handled only 90 entries per hour rendering the service too expensive to be commercially viable.

You can see how a similar approach would work in a lot of speech systems. A computerized voice agent could handle incoming calls for a call-center, up to a point where it is no longer sure what to do and then direct the call to a human call center worker. Some calls would be completely handled by the agent, while in other cases it would at least be directed to the right person along with all information that the agent has gathered already.

But it applies in many other situations as well. Take the hot topic of spam-filters as an example. How about a system that would only filter out automatically the spam that it is 100% sure about, but the “could-be-spam” messages would be sent to a human agent (at spam filter co.) that would decide what to do. This would also speed up the identification of new spam messages in circulation. Cloudmark uses a somewhat similar approach, but relies on the opinion of the masses, probably neither as efficient nor accurate as my proposed method.

Other scenarios where human/computer systems could apply include:

• Email answering: Already used quite a lot in help desks to suggest appropriate standardized answers to incoming queries.
• Computer vision: Automatically identify the simple stuff but send the harder to recognize stuff to human interpretation.
• Advanced proof reading: Again transmitting your document to someone that would actually read it for spelling and grammar errors and even suggest better wording. Done transparently from within the application. An estimated time of completion would be visible right away. Users could even pay a premium for prioritization.
• Layout: Transparently sending e.g. your draft PowerPoint presentation to a layout person that would make sure it looks nice, do touch-up on the graphics, etc.
• Translation: Transparently sending your document to a professional translator that does the job and returns it to within your application.
• Web search: A human operator could help a user find relevant information on the Internet. Enter your query in natural language and you will receive a response with human-picked pages that are relevant to your query.

In all cases, what sits on the “other end” doesn’t matter to the user. The tasks are completed and he doesn’t really care how it’s done. The service provider can gradually work to automate more of his work, without the user ever noticing.

So, are there any modules in your freshly drawn software architecture that could be replaced with humans for improvement or enabling of new features?