Donald Belcham keeps me on the TDD path

Inspired to do some penance following a late-night “there’s a bug in the app” call (OK, 10pm isn’t late, but it’s later than I want to be working), I spent some time yesterday working TDD-style, which I’ve played with before, but this time using mock objects, which I’ve never used but have the potential to make my tests actually meaningful.

The net result?  a thirty minute job took three and a half hours.

Granted, some of that was learning curve.  A lot of that was learning curve, really.  Still, it took a lot to keep telling myself that I shouldn’t abandon TDD, MVC, etc. and just go back to stuffing everything in the codebehind.  After all, I’m competing with other companies whose developers do that, and fast turnaround is all the client cares about, right?

Well, I’m keeping at it, and it’s Donald Belcham‘s fault.

After a long day of patching code and getting the crap kicked out of my by new tools, the last thing I wanted to do was go to a user group meeting and listen to someone talk about Alt.net, but somehow I managed to drag myself there (the fact that the venue was almost directly on the way home helped a lot.)

Wow.

I thought that the talk was going to be mostly about CC.Net and nAnt (which was the original plan, apparently), but it ended up being a two-parter:

1) How to be a better developer

I can’t tell you how much I needed to hear that what I was going through was normal, that nearly everyone gets kicked in the teeth when they start changing their development style, that the code I’m writing now is going to embarrass me in six months, and that it’ll all be worth it.

In the daily scramble to juggle multiple projects (before we finally started hiring), I lost track of what I loved most about software development: continuous personal improvement.  Donald pointed out that learning to write good code just like going to the gym: you need to practice regularly (he had an interesting practice of holding “corporate retreats” where he’d hole up in a hotel for a weekend just to write new code.)

I really wish that our new hire was able to make it to the talk.  Now he’s going to have to listen to me go on and on about it.

2) Code examples

Time was getting tight, but Donald managed to show us some examples of Monorail, which is apparently the most production-ready MVC framework for .Net out there right now.  I need to take another look at it – while there are some issues with NHibernate and MySQL, it’s a good candidate for a practice session.  If nothing else, I jotted down about a dozen future search terms for the google.

I wasn’t able to implement any of the ideas right away due to some other deadlines, but I did manage to see my TDD adventure in a new light.  Yes, it was a frustrating few hours, but in the process I managed to come up with a new refactoring for our data access layer that looks promising, I discovered a few coding practices that I need to stop (boolean functions that always return true, for example), and in theory I’ve got code that’s going to warn me if I inadvertently break it by making a change somewhere else.  Cool.

Thanks again to Donald as well as the Metro Toronto .Net Users Group for hosting the talk.  I went in wishing there was wireless so I could get some work done, and I left regretting that I couldn’t stick around for drinks.  I don’t want to tag it as “life-changing,” but I think it’s pushing me down a path that’ll make for an interesting few months while I try some more of this stuff out and see how it fits in our organization.