Microsoft Sneaks Across the Rubicon

  Posted by Darrell Knight on March 21, 2008

I remember several years ago Steve Ballmer (or was it Bill) said something along the lines of “if I could get $10 a month for every single Microsoft customer I would never need to sell another software license.”

Well I think that day may finally be coming. I attended a Microsoft Conference in a suburb of Chicago last week and amongst the Powerpoint overload and mumbled presentations by some newby Microsoftees they stated that they want to give the customer a choice of buying their hosted Microsoft solutions from a partner or direct from Microsoft. What…backup a minute…did you say direct from Microsoft. Apparently this had been announced a few months ago, but based on the subsequent “gulp” that emanated in the audience I can only assume they all missed the memo.

Well the MStees did have a legitimate explanation – “that’s what Google is doing” (oh and a few other like eBay and Facebook – huh?) so we have no choice – of course! Now for a company that prides itself on its partner programs this seems a little disingenuous, especially when they announced a couple of earlier slides how many hosting partners they had managed to sign up since they launched the program.

They have coined an interesting term to further obfuscate the concept – “Software + Services Channel” which sort of, kind-of, means “Software-as-a-Service through the Channel”, but clearly this was not the full story.

Anyway, most of the partners in the audience took it well. After all 1) they have no choice and 2) their customers would never buy direct from Microsoft. Why would they, I mean what would they get from the mothership that they could not get from Larry down the street. Of course people will pay a premium to shop locally, everybody knows that. Did somebody say Walmart…

Well it might take a while, but $10 multiplied by the entire population of the planet (other than the Chinese who use their own stuff) is a big number to be getting every month. Both Steve and Bill will be very proud one day.

.NET or Java in Speech

  Posted by Lowell Clark on March 11, 2008

Recently, I had the pleasure of running into someone who called .NET “archaic” and craptastic”. It was apparent from the rest of the conversation that this wordsmith had a bias towards Java and open-source. For the rest of this blog we will call this person “John Smith”.

Disclaimer: I have limited knowledge of Java and its environments, but from what I have seen, I prefer the .NET languages and environment over Java.

So, I decided to do a little research to find out why someone would have chosen these words to describe a language and environment that I enjoy developing in. During my limited research I came across the following two blogs.

http://blogs.zdnet.com/ITFacts/?p=5890
http://rwatsh.blogspot.com/2006/12/java-vs-net.html

I am sure you all know that you can not believe everything that you read on the Internet, so I decided to hunt down one of my previous co-workers who has developed both in Java and in .NET. This previous co-worker indicated that he preferred developing in the .NET environment.

So far, I have concluded that both .NET and Java are very good and mature environments and have their own strengths and weaknesses. I also believe that the verbiage used to describe the .NET technology by John Smith is not backed by any factual information and was most likely an emotional outburst because of stress from an external source.

I am still intrigued by this topic and would like to do more research on it, but for now, I must let it go. I would like to hear the opinions from the speech community on this topic. Do you prefer .NET or Java, and why?

Disclaimer: The information, ideas, and opinions expressed in this blog are mine alone, and do not necessarily reflect those of Message Technologies, Inc.


Cowboys vs. Farmers

  Posted by Laura Chumley on March 6, 2008

One of my very favorite customers (that’s you, Carl) asked that I return to an earlier post and offer some suggestions to replace the list of 10 things that should never again be spoken in an IVR application. Well, I will get to that highly contentious debate one of these days, but today I want to share an excerpt of Bruce Balentine’s excellent summary on the VUI design and gethuman.com war of words.

…”the gethuman effort is really about the proposition that an IVR and a call center agent together represent a single *system* that has one goal — delivering service to a caller. I think everyone agrees with that. Gethuman is generally right about the spec. This vuids group is right to be a bit incensed that non- designers can or should specify exactly *how* those specs should be rendered. If designers can agree to accept specs from non-vuids people, then the spec people should be willing to capitulate on details of the design itself. Then there would be a larger community with one common goal — delivering service to callers.” Read the entire post

His point was that functional specification and the design principles need to be segmented. They are a complementary pair—two mules pulling the wagon. Form needs to mold function to get the job done in the best possible way. That’s right. The cowboys and the farmers can be friends.

Gone Vishing

  Posted by Justin Simkavitz on March 5, 2008

You may be wondering why I misspelled fishing, I’ll get to that momentarily. Here in Atlanta it’s getting to be that time of year again when my friends and I happily ignore our Blackberries, choosing to spend the better part of our Saturdays relaxing on Lake Allatoona with full tackle boxes (coolers). By no means are we serious anglers, but in today’s fast paced world, fishing is a lot cheaper than a trip to the therapist. To date, my greatest achievement as an angler here in Georgia is getting a three-pronged lure stuck in my brother’s leg. Well, there was that time I battled a ferocious sunken log for about fifteen minutes, but that’s another story.

Unfortunately, spring time has also brought out a different type of fisherman, Vishermen. Most of us know about Phishing scams where crooks send an e-mail which links to a bogus website designed to fraudulently obtain things like account passwords and credit card information. If you are not familiar with Vishing (Voice Phishing), much like phishing, the goal is to persuade victims to divulge personal information by claiming that their account has been deactivated or terminated. Vishermen use two types of bait to hook people, outbound telephone calls and e-mails. Both methods notify the potential victim that there is a problem with his/her account and they need to call a certain number in order to remedy the problem. When the victim bites and calls the number, a rogue IVR system answers the call and proceeds to collect personal information. Vishing in not entirely new but the Internet Crime Complaint Center (IC3) has recently seen an increase in the number of incidents related to Vishing http://www.ic3.gov/media/2008/080117.htm

With a wide variety of VOIP providers now offering low cost alternatives, creating a functional IVR system using cheap computers and inexpensive software is easier than ever. I got to thinking about how these systems would sound and it should be relatively easy for a trained ear to recognize if you’ve gone vishing.

Top 5 signs that you’ve Gone Vishin’:

1. The system uses Text-To-Speech for all prompts - Any respectable financial institution will use a professional voice talent. Scammers choose to use text-to-speech because it is inexpensive.

2. Busy Signals – Banks and legitimate businesses should always have enough telco capacity to handle every call without busies. Busy signals would be common with the fake system because it’s probably sitting in a garage and only has two stolen port licenses.

3. The system accepts any input – Obviously a rogue system would not have any backend integration so the system will gladly accept a two hundred digit account number, followed by the pound sign of course.

4. Everything is confirmed – Even if you know for a fact that you entered your account number correctly, the scammer does not want to risk this great opportunity to steal your identity so the system will either read the info back or have you enter it again

5. The telephone number is not toll free – If you have to dial a number that is out of state or starts with 976, this is probably not a legitimate system.

A few other signs to watch for:

  • After entering all of your personal information, the synthesized voice announces “GOTCHA, NOW TELL YOUR FRIENDS TO CALL. GOODBYE”.
  • The on-hold music is “Money” by Pink Floyd
  • The agent puts you on hold to go find “some paper and something to write with”
  • The next day when you notice your account balance is $0.00, you call the number again only to reach “Hanks Auto Emporium”
  • After pressing zero to speak with an agent, you reach someone located in the U.S.
  • Great VUI design - most financial institutions are not known for well designed systems

Vishing is just the latest in a long line of scams designed to steal your personal information and identity. With a new scam popping up every day, protecting your personal information is more important than ever.

The Art of Estimating

  Posted by Mark Abramson on March 4, 2008

One of our main objectives at MTI is to provide speech solutions to customers. In order to get buy-in from potential stakeholders, we have to provide accurate estimates of the cost of development of these solutions. Remarkably, there is little objective research on what a “typical” speech dialog should cost. Of course any dialog can be simple or complex and have one or more simple or complex grammars. But it seems like we should have enough experience and enough talent to be able to effectively ballpark the costs. And we in the industry do, sort of.

Many of us have been taking our estimation process seriously for quite some time. Others simply try to price development work on the basis of how an application can save money when compared to live agents (for purposes of this blog, I’ll call that “value pricing”). That might work one time, depending on whether the prospective customer has done any competitive shopping. This kind of pricing gives the competition an easy opportunity to undercut based on the “true” costs involved in developing and supporting an application; true costs, even with reasonable profit margins baked in, invariably are lower than the costs proposed by value pricing.

Try as one might, value pricing just won’t hold water these days. If the client was naïve enough to accept it the first time, they’ll most likely be better educated by the time a new project rolls around. The incumbent has a distinct advantage, for sure, but price drives sales. So we at MTI believe the way to encourage more speech applications is to develop what the customer wants at a cost that reflects the actual software development effort.

The key to turning the art of estimating into a science is to have solid history of what it took to build prior projects and to use that history to build ever more accurate estimates. And yet most developers and engineers consistently seem to ignore their history and continue to underestimate what it takes to fabricate and support quality applications. Why is that?

I think it’s because developers and engineers look for ways to be appreciated. Too often they aren’t. Deep down they know that they’ll get a big smile and a pat on the back if they promise to deliver anything at a low person-hour count. Pleasing your boss is a good thing, right? That works well until an “estimate” is missed, usually by someone announcing that a deadline is slipping by x days, weeks, or months. Too often that announcement comes very late in the development cycle. Then your boss isn’t so happy. And neither is the customer.

The trick is to motivate engineers to provide accurate estimates by rewarding accuracy. It is equally vexing to have estimates that are too low or too high. Neither does anyone any good.

So for a number of years now we have implemented a systematic approach to estimation where we look at the number of dialogs, database interfaces, web services needed, prompts, ongoing analytics, etc. to construct a reproducible, reasonable, and realistic estimate of what it takes to make and support something. Sometimes the numbers are surprising. But because of the granularity of the estimate, they are hard to argue against.

Honestly, it is a process that has no end. But it is a measurable process and we have made good progress. And, not surprisingly, our estimates continue to go down as we gain more and more experience and develop more and more reusable modules. Soon we will be able to actually tie a portion of our engineers’ annual reviews to how accurate they are in their estimates. That’s a good feedback loop. And a great motivator.