A colleague and I were chatting the other day and we were talking about STL implementations (in the context of a broader discussion about template meta-programming and how difficult it is).
During our discussion, I described the STL implementation as “read-only” and he instantly knew what I was talking about. As we dug in further, I realized that for many languages, you can characterize computer languages as read-only and write-only
Of course there’s a huge amount of variation here – it’s always possible to write incomprehensible code, but there are languages that just lend themselves to being read-only or write-only.
A “read-only” language is a language that anyone can understand when reading it, but you wouldn’t even begin to be able to know how to write (or modify) code in that language. Languages that are read-only tend to have very subtle syntax – it looks like something familiar, but there are magic special characters that change the meaning of the code. As I mentioned above, template meta-programming can be thought of as read-only, if you’ve ever worked with COBOL code, it also could be considered to be read-only.
Of course anyone for someone who’s very familiar with a particular language, the code written in that language is often understandable – back when I was coding in Teco on a daily basis (and there was a time when I spent weeks working on Emacs (the original Emacs written by RMS, not the replacement written by Jim Gosling) extensions), I could easily read Teco code. But that’s only when you spend all your time living and breathing the code.
 I can’t take credit for the term “read-only”, I first heard the term from Miguel de Icaza at the //Build/ conference a couple of weeks ago.
 “line noise” – that’s the random characters that are inserted into the character stream received by an acoustic modem – these beasts no longer exists in todays broadband world, but back in the day, line noise was a real problem.
As many of you may know, I tend to blog about things I encounter in my day-to-day work that I think might be of general interest. And for the past two years, even though I've run into things that were "blog-worthy", I couldn't write about them in public. And thus no blog posts.
But that's changed now that the //Build conference is over. I can finally talk about some of the things I've worked on over the past few years. Most of the things will come through more official channels: the "Building Windows 8" blog, the windows dev center, etc. But I do hope to write more about what I have done in the past and what I'm doing these days.
So what *have* I been doing for the past two years? After we shipped Windows 7, I moved from the Windows Audio team to a new team known as the "Runtime Experience" team. The Runtime Experience team is responsible for the architectural elements that make up the new "Windows Runtime" which is a part of the next version of Windows. My development manager, Martyn Lovell gave a great talk at the //Build conference about the runtime here.
My work has focused on developer tools to enable authoring windows runtime APIs and designing the metadata format used to represent the windows runtime APIs. It's a bit esoteric and geeky, but I've had a huge amount of fun working on this over the past two years.
Anyway, that's a very brief version of my job, and as I said, I hope to be able to write more often in the near future.
I'm at the build conference in Anaheim this week, and I was in the platform booth when a customer asked me a question I'd not been asked before: "How do you get started with test driven development". My answer was simply "just start - it doesn't matter how much existing code you already have, just start writing tests alongside your new code. Get a good unit test framework like the one in Visual Studio, but it really doesn't matter what framework you use, just start writing the tests".
This morning, I realized I ought to elaborate on my answer a bit.
I'm a huge fan of Test Driven Development. Of all the "eXtreme Programming" methodologies, TDD is by far the one that makes the most sense. I started using TDD back in Windows 7. I had read about TDD over the years, and was intrigued by the concept but like the customer, I didn't really know where to start. My previous project had extensive unit tests, but they really didn't use any kind of methodology when developing them. When it came time to develop a new subsystem for the audio stack for Windows 7 (the feature that eventually became the "capture monitor/listen to" feature), I decided to apply TDD when developing the feature just to see how well it worked. The results far exceeded my expectations.
To be fair, I don't follow the classic TDD paradigm where you write the tests first, then write the code to make sure the tests pass. Instead I write the tests at the same time I'm writing the code. Sometimes I write the tests before the code, sometimes the code before the tests, but they're really written at the same time.
In my case, I was fortunate because the capture monitor was a fairly separate piece of the audio stack - it is essentially bolted onto the core audio engine. That meant that I could develop it as a stand-alone system. To ensure that the capture monitor could be tested in isolation, I developed it as a library with a set of clean APIs. The interface with the audio engine was just through those clean APIs. By reducing the exposure of the capture monitor APIs, I restricted the public surface I needed to test.
But I still needed to test the internal bits. The good news is that because it was a library, it was easy to add test hooks and enable the ability to drive deep into the capture monitor implementation. I simply made my test classes friends of the implementation classes and then the test code could call into the protected members of the various capture monitor classes. This allowed me to build test cases that had the ability to simulate internal state changes which allowed me to build more thorough tests.
I was really happy with how well the test development went, but the proof about the benefits of TDD really shown when it was deployed as a part of the product.
During the development of Windows 7, there were extremely few (maybe a half dozen?) bugs found in the capture monitor that weren't first found by my unit tests. And because I had such an extensive library of tests, I was able to add regression test cases for those externally found tests.
I've since moved on from the audio team, but I'm still using TDD - I'm currently responsible for two tools in the Windows build system/SDK and both of them have been developed with TDD. One of them (the IDL compiler used by Windows developers for creating Windows 8 APIs) couldn't be developed using the same methodology as I used for the capture monitor, but the other (mdmerge, the metadata composition tool) was. Both have been successful - while there have been more bugs found externally in both the IDL compiler and mdmerge than were found in the capture monitor, the regression rate on both tools has been extremely low thanks to the unit tests.
As I said at the beginning, I'm a huge fan of TDD - while there's some upfront cost associated with creating unit tests as you write the code, it absolutely pays off in the long run with a higher initial quality and a dramatically lower bug rate.