iLude

What’s in your wallet? – Part 2

I felt I should follow up on my post from yesterday. First I want to say that I’m not trying to bash Jeff or otherwise rub his nose in it. Jeff has stated that he learns best from the “Smackdown”. And I’m nothing if not confrontational

As I stated, my first dealings with Ayende were back around 2003 or so when the company I worked for tasked me with developing a new webmail program. The previous version had been written in java and functioned but lacked many features that our customers were asking for. At the time the company had the grand idea of the “standard language”, and following the “no one ever got fired for buying Microsoft” logic mandated that C# was to be that language.

One of the major hurdles I ran into was the lack of a performant pop3/mime library. Many were tried but most relied on regular expressions to parse the messages and this would bring the server to its knees if more than one or two users attempted to open their mailbox at the same time. So off I went to write a mime parser. 

At the same time I was also submitting patches to Monorail to get the NVelocity engine working on mono. Hammett gladly accepted those patched and even gave me commit privileges. But both he and Ayende endlessly encouraged me to create tests for the functionality I was patching. Sadly I knew nothing of how to write a unit test or even how to run one if I were to write one.  And so patches were created and applied and mime parsers were written and used all without a single unit test.

At first my world was a fairly happy place, but then came the spammers. One of a spammers favorite tricks is to mess with the headers of an email in an attempt to create a header that is read by the client but which can slip past spam detection software. Having a homegrown mime parser deal with these types of emails can quickly takeover ones life. And since the parser had been written fairly quickly and I’m a self taught programmer the parser had, shall we say, a significant amount of technical debt!

I was about to take the road so often traveled and start over from scratch on a new mime parser. But this time I decided that after reading up on TDD I would start this attempt writing tests. So I downloaded Nunit and TestDriven.Net and started coding.

At first it was awkward. But very soon I fell into a rhythm and within a few hours had a basic working parser and a fair number of tests to go with it. I created tests that called the new parser in the same way the existing code called the old one.  Then I began working with the library of spam messages I had build up for debugging the current engine, creating a unit test for each message. I would compare the output of my parser against the output of another known parser to assure that I was getting the correct data into the correct places in my object model. Soon I was even parsing messages that several of the known parser would fail on. And as new messages came in that failed with the old parser I was able in a matter of minutes to create a new unit test for that message on the new parser.

Sometimes a message would cause the tests to fail, and so I would make changes and get the tests to pass. Then I would rerun the entire test suite and find that the changes I’d made to would cause an old message to be parsed incorrectly. And so further changes were made until all the tests passed. And it was at one of those times that I became a TDD believer. I realized the incredible value that TDD brought to my development.  I had created a zero friction environment to code this parser in.

But there was more to it than just the tests. The code I was writing was cleaner and had far better separation of concerns. The changes I needed to make were easier to make. The other principles that Ayende and other members of the Castle Project were talking about, like SRP and IOC, were much easier to implement and the value of those patterns were much clearer.  This one project by no means made me an expert, but it certainly showed me that there was more value to these principles than I had previously thought. And that encouraged me to continue learning about those principles. That learning has continued to this day I firmly believe that I am a much better programmer for it.

In my next post I’ll try and address why any of this matters and how Jeff’s response is shortsighted at least and incredibly destructive at worst.