mattdavid.net

CodeRush is one of the greatest tools I’ve ever used in Visual Studio.  Quick navigation, code templates, re-factoring, all kinds of goodies to help make working with code easier.  Even though CodeRush has some  great features, it’s two main drawbacks are not everyone uses it and it only works within Visual Studio.

Tonight I felt a little like Scotty in Star Trek IV: The Voyage Home:

[faced with a 20th century computer] Scotty: Computer. Computer? [Bones hands him a mouse and he speaks into it] Scotty: Hello, computer. Dr. Nichols: Just use the keyboard. Scotty: Keyboard. How quaint.

So tonight, I’m just happily writing an email when I realize that I want to select a bunch of lines to move them.  So, what do I do?  I start hitting the ‘+’ key on the numpad.  In CodeRush, this will start selecting text, increasing the selection scope with each press of the ‘+’.  I finally stopped after 3  or 4 presses when it finally dawned on me that all I was doing was typing ‘+’.

“Oh,”  I thought to myself, “this isn’t Visual Studio.”

How quaint.

Git is the new hotness.  There are other distributed version control systems, but git seems to be the one that’s taken off the most from what I’ve seen.  There’s Mercurial (the command “hg” is pretty sweet) or Bazaar (does anyone use this?), but it seems that most all of the projects I’m interested in that use dvcs are using git (I’m looking at you IronRuby.)

Git may be a bit confusing when you first start working with it, but fortunately, http://gitready.com/ has a bunch of tips for dealing with git day to day.

I was recently reminded of this by Scott Bellware on this hanselminutes episode.

It’s easy to fall into the trap of thinking about TDD as a testing technique.  I mean, Test is the first word in TDD.  And normally you hear it talked about as Test Driven Development, not Test Driven Design.  Since most development going on is probably not Greenfield, but is in maintenance/support mode, I’d bet that those involved with most applications think that the design phase is “done”.  Even when new features are being added to an existing application/platform, it’s not like you’re starting from scratch, you’re usually bolting things on to existing functionality.

And therein lies a pitfall.  Most people would probably be more concerned with not breaking existing functionality, as opposed to letting TDD help design the new functionality.

Another pitfall comes from that first word, Test.  Don’t get me wrong, I love tests.  However, it is quite possible that you follow the red/green/refactor methodology of writing tests and still come out with poorly designed code. This comes from what I like to call the “Mother of Invention Principle”.  Yeah, I just coined a principle.  Basically, one of the ideas of TDD is that there should be no new code added until it is required by at least one test.  So, if you follow this principle, then you should technically have 100% code coverage when finished.

Unfortunately, 100% code coverage isn’t useful.  Anything but 100% would be useful (but more on that in another post.)  Maybe the tests were poorly designed.  Maybe the tests are spot on, but they require huge amounts of setup and teardown for each test.  Sure, it’s tested, but is it designed well?

This kind of thinking, about “fully” tested code, sure make TDD a good sell to management and QA, but alas, that’s not what TDD was meant for.

Anyway, I won’t belabor the point, listen to the podcast.  Scott and Scott talk about this much more eloquently than I can.