It's been about two and a half weeks since my last post. My project is coming along nicely; I've written a total of about 100 lines of code. I've spent at least an hour, every day, working on some aspect of the site. I guess my point is to illustrate how much planning needs to occur before you even write a single line of code.
I think of every application as the creation of building blocks for my next application. Given this, I tend to labor over the details to ensure that I'm creating a solid framework and not just a one-off web site. While I'd agree with anyone that labeled me as neurotic or obsessive-compulsive, I think this kind of mentality bodes well for a programmer.
I see programming as a craft, and, as such, I'm always looking for ways to better myself. In an effort to "future-proof" my design, I'm forced to bring in new technologies and push myself out of my comfort zone (though I'm never really comfortable stagnating.)

One example of this is my epiphany with regards to test-driven development (TDD) (or behavior-driven development.) See, I find myself stuck in traffic for at least an hour every night. During this time, my radio is either off or playing a programming-related podcast. As of late, I've listened to all my podcasts, so it's just me, the road, and my thoughts (and thousands of other motorists).
So, as I'm working through a particular aspect of the framework of my application in my head, it suddenly clicks: this is a perfect place for TDD. You see, my mind kept wanting to traverse the tree of functionality all the way to the leaf nodes, but right now I only really need to set the stage/build the trunk for those nodes. I was spending all of my brain power trying to decide how to flesh out the entire design, when I had a solid starting point that could/should be the focus right now.
When following the single-responsibility and open-closed principles TDD is just a perfect fit. You can create your "trunk" and then mock out all of the nodes. You create the nodes later and test them independently. Suddenly, it all made sense.
You see, prior to now, my development workflow was never compatible with the TDD workflow. I was always trying to make sure I had all my nodes in good order, then put the trunk together (or some amalgamation of that.) While I've always fully embraced unit testing, I never bought into the test-first pattern. But, it occurred to me, that it's not "test-first" its more "behavior-first" or "foundation-first."
This epiphany would have never struck me if I hadn't spent the last couple of weeks writing some test code and trying out Moq for the first time. Once I started to see what these tools offered, I realized the development friction would actually be lessened by viewing the application's development with a TDD bent. Then, with enough mind-numbing focus during my time in traffic, all of the puzzle pieces fell into place.
I have to say, this new perspective has added a new level of excitement to my development; it's empowering.
With that, I've settled on a tech stack:
- MS Windows Server 2008 R2
- MS SqlServer 2008
- ASP.NET MVC 2 (beta for now)
- nHibernate
- Fluent nHibernate
- Moq
- MS Testing Framework (I like the integration with the IDE)
Now, my choice to use nHibernate is the topic of another discussion. I have always been firmly against OR/Ms, but nHibernate impressed me so much that I decided I couldn't go wrong - as long as I take to the time to understand how nHibernate is expected to be used.
I will say that I started down the LINQ path with great enthusiasm, but it really had all of the bad elements of an ORM and none of the good. I can't live in a world with out POCOs, sorry. I will not "work around" any library - they are supposed to help make things easier, not bleed their abstraction all over your code. *stepping off my soapbox*
Perhaps I'll go into my decision to use nHibernate after I get some hours behind the wheel so I can reflect on my decision.