On Code-Generation Tools

The 90th Percentile had an article bashing code generation as a programming technique. He is suspicous that visual programming is no better (and in many ways worse) than textual programming. The generated code is often unreadable, and in the case of proprietary tools, you'll be forever dependent on the tool vendor for bug fixes and updates.

The IVR industry is especially wed to visual tools, because they actually work well. For DTMF apps, that is, whose structure is basically a tree. However, the tools promote the anti-pattern of putting all the business logic in the IVR equivalent of the onClick event.

I would defend code-generation for cross-language problems such as build and deploy tools, or backup tools that are a combination of code and scripts.

Mondrian at Google

Python's inventor Guido van Rossum is at Google. His first project was a tool for code reviews called Mondrian. Described here and in a video.

This is a revealing glimpse of a 21st-century software development organization.

• Heavy use of tools to automate the organization's own development process.
• Social not silos. Developers can view other developer's Mondrian dashboard. The tool is an enabler, not a rule enforcer. The review process itself builds relationships between senior and junior staff.
• Save everything. Mondrian saves every reviewed source file and all comments. Great for resolving customer problems months later. Also great for tracking metrics.
  

Other notes

• data encrypted on HD so when throw out server no privacies worries
• Google uses perforce (p4) but no developer branches! Means code reviews must work with files on dev machines. They use NFS so anyone can browse anyone else's machine
• runs on one box! in python
• uses Google BigTable
  

Replacing the OS

Marc Andreesen once said that "the combination of Java and a Netscape browser would relegate the operating system to its original role as an unimportant collection of slightly buggy device drivers." Pretty funny, considering Microsoft has fifty billion in cash and Java is nowhere to be seen on the desktop.

Yet the idea remains tantalizing. Change the phrase to "JavaScript and a web browser" and we have AJAX. Or Adobe Flex. Or Google Gears.

In fact one could make a thin client platform out of one of these AJAX technologies and then replace the OS with a minimal set of services, like the GEOS operating system. Feasible but highly improbable, at least on the desktop. Yet if some new device appeared, larger than a cell phone but smaller than a laptop, it's a whole new ball game. Instant-on is a feature I would dearly love to have, and it's not going to happen on Windows.

Speech to Text coming to cell phones

This video introduces Morpheus's upcoming speech to text technology. The reason this is important is audio bandwidth. The phone network is based on 64 kbps audio of 4 KHz bandwidth, which is fine for humans to understand but is missing a lot of the higher frequencies that speech recognition engines need to improve their accuracy. That's why phone-based speech rec uses discrete grammars, which are simpler to recognize. Desktop speech rec can do full dictation because a high-quality audio path exists.

Morpheus (and others) use network-based speech rec. The user's device captures the audio and does some basic processing before streaming it as data. Network-based speech rec engines receive the data, do the recognition, and send back the recognized text. Not only does this avoid the audio bandwidth problems, it also avoids running the speech rec engine on a CPU-limited cell phone.

This still isn't perfect dictation accuracy. The Morpheus video mentions about a 10% error rate. So it's still not really ready for dictating blog posts from your phone, but the accuracy is tightly tied to CPU power which improves every year.

As the VUI design blog says, the recent acquisitions of BeVocal and TellMe is perhaps being driven by interest in network-based speech.