It's almost synchronicity, the way the "friction" meme from last night's Test-Driven Development presentation seemed to carry over into today. In the proverbial nutshell, the basic idea is that the less fiddling (i.e. friction) is involved in toggling between writing code and testing it, the more likely it is that things will be tested early-on. As anyone outside as well as inside the trade can imagine, that's a very good thing--the earlier a bug is found the cheaper it is to fix.
Today I had to dig out a bit of legacy DLL code written in Visual Basic 6. I actually didn't mind the language itself, but boy-oh-boy, do I ever have a problem with its compiler--specifically its little quirk of not unlocking the compiled code file after it's done. To date, my co-workers and I have found but one solution: Reboot. There's no euphemizing: That sucks swamp-water. Specifically, a swamp sandwiched between a swine-farm and a Superfund site.
But in this case, there's a workaround of sorts. Visual Basic 6 has a web language counterpart, VBScript. Think of them as two half-siblings who take after their common parent in looks but aren't as similar as they might be. But the resemblance is close enough that I can copy the new VB6 function into a web page, make a few tactical replacements, cheese out some wrapper HTML code to validate output, and testing is only an F5 key-press away (with maybe a right-click-and-pick-"View Source" tagging behind every few reloads) . When I'm pretty confident that the code's doing what I want it to, it's just a matter of reversing the replacements, and pasting it back into the DLL source.
But the point is that it's ridiculous that I have to do that at all. Mercifully, it's not like VB6 and I are the BFFs we were eight years ago. (Okay, so maybe we weren't BFFs, even Back In The Day. But still...)
