Starbucks-fueled Developer

Sunday, June 11, 2006

My Tour of Agile Development

While I've posted on using/doing Test Driven Development in the past, I have a few confessions to make. First, when I started blogging (about a year ago), most of my "unit tests" where really more integration tests. I had very little understanding of why mocking the database was so important and that introducing such dependencies on your tests just increases the fragility of both testing code and code-under-test. Second, I really haven't had the opportunity since my "blogging premire" to really work on any project with a true Test Driven approach. I did, however, recently have the opportunity to coach someone through the process of using NUnit, etc. and he picked it up nicely and thusly became test-infected.

With my new job, I have a lot of opportunities coming my way to embrace, learn, dare I say perfect the practice of Test Driven Development. I have already done so with the current project I'm working on; you know, one of those "all I need is a little application with one or two screens for a user to enter some data once a [insert timeframe here] so that I can easily run my reports every so-often". Some - nah, gotta go out on a limb - most applications are not that little. If reporting and a database are involved, you're looking at an easy month to two months...But I digress...

So my first lesson learned, from the past 10 or so days, is that I broke probably the number one rule of agile development: "Working software is the primary measure of progress". I spent way to much time focusing on how to abstract out NHibernate, how to set Team Foundation Server so I had tasks and other Work Items to report defects and code coverage against, and ensuring a "sound" LAYERED ARCHITECTURE just to name a few. The point is this: up until Friday, there was not a binary available in the SCCS for the customer to have that they could see/measure progress on the application.

Bad...nay...Unacceptable.

Now, I did hit a few roadblocks with SQL Server not running, not having the right edition of VSTS installed, and time spent in thinking out and analyzing the application but they don't excuse the fact that, if I were the customer, I wouldn't feel very comfortable at this point in the project. Needless to say will change tomorrow.

Aside from all of these mishaps, the one that concerns me the most, and until now unmentioned, is the fact that I'm essentially working on the application alone. There is another guy doing the reports but, sadly, I'm running the show. Sure it feels great to be trusted and the feeling of confidence that gives is wonderful, but I need my work to be validated aside from the customer saying "yup, that's exactly what we were looking for!". I mean, I can teach a 12-year-old to program [read: drag 'n' drop their way to a working ASP.NET 2.0 database application] and give their work to the customer, but that doesn't make me feel confident in what I produced.

I hope to post more on what I have learned thus far about, getting into greater detail about my takes on TDD and other important matters in the future...

1 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home