That time I saved Microsoft’s Developer’s Division a lot of money…

The Situation: 2003 — Visual C++ product unit were updating the .Net extensions and with the blessing of the ANSI committee incorporating that functionality into the C++ language specification, resulting in the C++ compiler v2.0 that conformed to this new specification. The problem — the default C++ compiler that was enabled was the v1.1 of the version with the managed extensions. Other product units in Visual Studio were exclusively using the v1.1 C++ compiler for unit testing, acceptance test suites, automation harnesses, etc. Even though it had been communicated broadly across the division that the new v2.0 compiler would become the default compiler in the near future, there was no effort to migrate their source code to the new ANSI version.

One Monday though, a broad distribution email went out across the Division, informing that one week from that day this new v2.0 compiler would be set as the default in Visual Studio builds going forward.

All the Product Units in the Developers Division responded negatively in multiple reply emails. One team that had the biggest impact was the WinForms team. The WinForms designer and universal UX builder was a common tool across all language packages in Visual Studio, and breaking their C++ unit tests, automation and all the actual source code files for the feature would be a disaster.

The Tasks: Initial estimates from the WinForms team for converting everything to the new syntax would take a team of 10 some 6–9 months of effort to complete. As a result, the WinForms Product Unit Manager made the explicit request that the C++ team assume responsibility for these tasks. The C++ team didn’t have the resources available to do this.

As necessity is the mother of invention, I determined that I could take existing work from two of C++ team’s architects (Herb Sutter and Stan Lippman) that showed how to use the .Net codeDOM to convert a line of v1.1 C++ code into a valid compilable v2.0 line of C++ code. Since all the teams in the division were using both the same SourceSafe repository, and also the MadDog CMS build and feature test automation framework — I knew had object model/exposed APIs that can be used to directly access/modify and create new files directly in SourceSafe, which meant I could develop a tool/script that could do non-destructive conversion of the source code into a new branch quickly and easily.

The Actions: I proposed developing a automation tool that would complete the code conversion and create new branches and test suites. I estimated a 2 week development and validation schedule to have all the affected files converted resulting in a significant reduction of risk on the overall Visual Studio release roadmap schedule.

I had a structure diagram that would use integrate all the above mentioned features into a single tool that would check out, load a file into memory, parse that file line by line, convert the code and write it into a new SourceSafe file, locally call an instance of the compiler in a CreateProcess() method to do a sanity check/compilation of the new file, and on success commit that file to the repository. Executing on the entire SourceSafe enlistment required traversing across source code for all product units in Visual Studio and enumerating the v1.1 C++ files to mark them for conversion prior to executing the script. It needed to be a non-destructive conversion, creating a duplicate file in a parallel branch for each source file and appending the original name with a “_v20” to indicate it was converted.

The syntax conversion tool was completed in under 4 hours with the remainder of day 1 testing using groups of files of varying complexity from C++’s own acceptance tests and source code instances. Next was programmatically accessing the SourceSafe repository, enabling tool access to create/modify enlistments, and executing on creating new files.

Integrating both sets of code together into one single application, and adding scope to my plan by writing the functionality to clone existing test suites with the new enlistment and trigger the unit and daily automation tests in MadDog to run on completion of the code conversions.

Final work was to ensure that each build of Visual Studio would have the C++ v2.0 compiler set to be the default in the Windows Registry, initiate the test run and send an email to me (as the temporary owner of the suite) with the results. 1 day of validation resulted in 15 sets of results of the WinForms test suites with results that matched exactly with the original v1.1 versions.

The Results: I set up a meeting for Friday morning 9 am with the entire stakeholder group from the prior meeting. I presented my application, demonstrated how it worked on a sample file and then presented printouts showing the results from 20 runs of the new suite in comparison with the original suites. There was a lot of surprise but also relief from all involved that the risk of slipping schedule from this issue was resolved.

To conclude the meeting, I made the executable and design document shareable and available across the division.