SALT in Skagit (Part 1)

  • Article

POSTED BY: GUNNAR KUDRJAVETS, MSS Software Design Engineer

Welcome to the world of software backwards compatibility! When we started working on a Microsoft Speech Server (MSS) 2007 (code name “Skagit”) our goal from day one was to ensure that SALT applications developed for previous versions, MSS 2004 and MSS 2004 R2 (code names “Kokanee” and “Lynnwood”), will work with a minimum number of changes required or no changes at all.

There have been some interesting technical challenges to make all this happen. Internally we re-architected our product, removed some dependencies and acquired some new ones, changed a number of internal interfaces, introduced new programming models etc. The usual stuff software developers like to do ;-)

In cases like this there are usually two basic ways to approach the problem of making applications developed for the previous version of a product to work on a new version:

  1. Start re-architecting and rewriting everything; there’s long period of time when nothing will work, and then you gradually start making things function again.
  2. Go from working solution to working solution or in agile software development terms –continuously refactor (https://www.refactoring.com/) your code. Every step of the way you’ll know where you are and you’ll notice immediately if you’ve broken any features or fixed some bugs.

Well, as none of us in MSS Runtime development team are much into gambling with the product’s quality, we chose the second approach. During previous versions of MSS our test team has developed thousands of test cases which exercise different aspects of the SALT standard (https://www.saltforum.org/) and different speech controls (https://msdn.microsoft.com/library/default.asp?url=/library/en-us/sasdk_salt/html/ST_Programmers_Reference.asp). For performance and stress purposes we have also developed internally a number of complex speech applications utilizing SALT and speech controls.

Therefore from the software engineering point of view the problem becomes making sure that all the applications and test cases which worked at the end of the previous MSS release will work exactly the same way during the upcoming release, no new bugs are introduced, and performance and stress capabilities are the same or better than the previous release. Looking back at the last 1.5 years I would have to admit that it’s been quite a challenge, but as a developer I had kilotons and kilotons of fun doing it. All the cool refactoring techniques I always wanted to try, all the unit testing you may ever wish for, and of course the mock objects ;-) In addition to all that, there’s also the necessity of having to be intimately familiar with code from all the versions of MSS. Like a kid in a candy shop ;-)

Next time: Minor changes we’ve made to SALT, a list of common problems you may encounter while porting your SALT applications over, and an introduction to the new SaltInterpreterActivity class which blends SALT applications into our workflow-based approach for MSS 2007.