Easier Doesn’t Always Mean Better

I’ve been doing lots of research lately into tools, languages and platforms aimed at making the process of building voice applications easier.

These new tools offer extensions to existing programming languages like PHP and JavaScript, or entirely new XML-based languages for building voice applications. Each of these new approaches has some appeal and each achieves (to some degree) the goal of making voice applications “easier” to build.

Still, these new tools raise some issues that may be reason for concern as well.

Before the advent of VoiceXML, languages and tools used to build IVR systems were vendor-specific. No standards existed that would allow IVR systems built for one platform to be easily and efficiently ported to another.

Certainly there are instances where designing an IVR for a specific platform may rank as a higher priority than making the application portable (i.e., if a platform supports a specific feature that is critical to the application). But having a standard language for building IVRs is good for developers too – if you can learn to build IVRs for one platform, your skills will be portable to other platforms (and to other jobs).

Building good IVR systems is hard. Really hard. Examples of poorly developed systems abound. This is one of the reasons that satisfaction with IVR systems is generally low, and why projects like GetHuman and Fonolo have developed.

But the direct relationship between difficulty and quality isn’t reserved to IVR applications. Building good visual web applications is really hard as well:

How many web applications have you seen where the developer(s) did not think about important issues like accessibility, scalability, security, etc.? How many development projects have you inherited or been involved with that contained poorly written, poorly documented or just straight up broken code? How many stories have you seen that described a web site or application that suffered from a critical security hole that compromised personal information?

I don’t think the answer to raising the satisfaction levels with IVR systems is to lower the barrier of entry (in terms of developer skill and experience) for creating them.

Is it harder for more junior developers to create sophisticated, secure, well built voice applications? Yes. And maybe it should be.