Solving Problems With Unsent Email Messages

I've found that an effective problem-solving strategy is to write an email message describing the problem. This happened in the last 48 hours to me.

First, I have a legacy program that does not have any formal unit tests. It was my first OO project and my inexperience really shows. Happily, I drank the Test-Driven Development (TDD) kool-aid a couple years back so my current code doesn't suck so bad. But living in a TDD mode makes maintenance of legacy code devilish. You get used to "TDD has your back" and when you approach your legacy code with that same fearlessness about refactoring its a high-wire act without a net. Ergo, I resolved to write unit tests for the new work that's required of it and also for any refactoring I choose to do.

More easily said than done. I have some experience with CPPUNIT and have applied it on some of my C++ work with some success. However, everything I have using CPPUNIT works in 32-bit Windows on the Microsoft C++ compiler. And this legacy system is a BORLAND 16-bit Windows application with a 3rd-party GUI library nobody uses anymore called zApp that I don't want to port to 32-bit Windows and the Microsoft compiler. How to add a unit testing framework to that? Pondering this question has kept me up some evenings. But the GLSEC conference this week thrust upon me the urgency to add unit tests and the guys at Atomic who use mock objects to abstract HARDWARE got me thinking.

I saw a way to start, but there were a lot of details that I didn't understand and I wanted some help. So, I started work on an email to a colleague describing what I was trying to do and what I had a hard time understanding.

The mere act of articulating a problem is a magical thing.

I jotted down the first steps I'd taken and where, exactly I was having difficulty. And then an idea occurred. I followed up on that idea to clarify my question and in so doing I found that the idea had solved that difficulty but had raised a couple others a little further along the path to solution. So, I edited my email restating the question as a backgrounder for the current difficulty nettling me. As you can probably guess, I was mid-description when another solution came to mind. And follow-up proved itself, and I edited the email to summarize the current state of my ignorance and so on iteratively until done.

I had a working program, but an email that was a mess of half-finished edits reflecting how much I didn't know at various points in the last few hours. I deleted the unfinished message, declared victory, and went to bed.

This pattern works with more than just emails. If you have a supportive wife, or cubicle-mate, or if you're pair-programming, just describing what you don't know suffices to organize your thinking enough to suggest a solution.