A few things have remained relatively constant, though, such as a command line.

And war... war never changes... (that's a Fallout reference!)

But I digress.

Given my love of all things command line, I still greatly prefer searching over the wide variety of code bases I've worked with from the terminal. I've blogged about this before and have even written a PowerShell script to help with this. Today, there are so many options available for text searching that I thought I'd share an updated list to help you decide how best to find text in your source code.

My test case will be simple... recursively search for the term "jQuery" across the current directory, optionally specifying the files to search in. Also, ideally show 3 lines of context after the match if possible.

The Old Standards

First off, I want to share the tools of the trade that have existed for years... decades even.

grep (cross platform)

Grep is the go to tool here. It's been around since at least the early 70s.

Often, you'll see grep used in conjuction with other tools, like ps to search for specific processes or other command line tools. By default, it just returns any lines that match the search term from stdin.

# use in conjunction with the find command
find "directory" -name "*.js" | xargs grep "jQuery"

# or more succinctly without find usage
# options:
#   -r        = recursive
#   -n        = line numbers
#   -w        = match whole word
#   --include = to specify files to search (like *.js)
#   -e        = search term
#   -A        = context lines to show (after match)
#   -B        = context lines to show (before match)
#   -C        = context lines to show (before and after match)
grep -rnw "directory" --include "*.js" -e "jQuery" -A 3

# look in current directory for jQuery across all files
grep -rnw . -e jQuery -A 3

To install grep, you either have it installed already because you're on a *nix platform or you can install it via Grep for Windows.

findstr (Windows)

Windows doesn't come with grep installed by default, but it does come with findstr.

In my humble opinion, while it can get the job done, you're much better off using one of the many other options out there. I don't believe it has any options to show context lines in its results.

Usage:

REM some relevant options:
REM   /p = skip files with non-printable characters
REM   /s = recursive searc
REM   /c = search term
findstr /p /s /c:"jQuery" *.js

No installation instructions - you're either on Windows and have it or you're not and don't need it.

Replacing grep

In the last 10 years or so, there have been a few stand out tools that have attempted to dethrone grep from its top spot of text searching, at least in terms of searching for code.

ack (cross platform)

ack is a perl script that whose original URL was actually "betterthangrep.com" - now it lives at beyondgrep.com. Given the original URL, you can probably guess how it is positioned - it is "a tool like grep, optimized for programmers." One of the key things for it is that it was built specifically for searching over source code. Grep doesn't know to ignore VCS directories like ".git" or ".svn". You often have to specify quite a few options to get to what you need.

Usage:

# relevant options:
#   --smart-case   = if set, ignores case unless the search term contains any upper case
#   -A             = context lines to show (after match)
#   -B             = context lines to show (before match)
#   -C             = context lines to show (before and after match)
#
# see also --help-types to see which file type groups ack supports
#   like --js, --csharp, --ruby, etc.

ack --js jQuery -A 3

To install, I'd recommend one of the following:

• Windows?
  • Install Chocolatey
  • Run choco install ack
• OSX?
  • Install homebrew
  • Run brew install ack
• Linux?
  • See list of packages

Find-String (Windows)

PowerShell was released in 2006. It shipped with a cmdlet called Select-String that provided grep-like functionality; however, it didn't support context matches until version 2. Multiple people built their own versions of wrappers around Select-String to make it more usable... I'm of course partial to my own Find-String project.

ack existed when I wrote Find-String, but it didn't perform as well for me at the time as using PowerShell (May 2009). Today, I'd guess ack and Find-String are fairly comparable in terms of performance.

Usage:

# relevant options:
#   -context   = [x,y] where x is number of lines before and y is number of lines after
Find-String jQuery *.js -context 0,3

If you have access to PowerShell 5, I've got Find-String up on the PowerShell Gallery. You can install it by running Install-Module Find-String.

If you're not yet on PowerShell 5, try installing PsGet and then you can just run Install-Module Find-String.

The New Players

In the last few years, there has been renewed interest in tools like grep and ack, but with speed as a big focus.

The Silver Searcher (ag) (cross platform)

In 2011, the Silver Searcher (ag) was released. To my understanding, it was the first code search tool since grep that was written in C. As a result, it performed faster than any of the competition. In the Linux and OSX communities, it was quickly gaining ground over tools like ack. In Windows, however, it was far too difficult for most people to get to compile in Windows. I used it when I was working in OSX, but I stuck with Find-String when I worked in Windows. However, recently I discovered pre-built binaries of ag for Windows that work great and out-perform Find-String by quite a bit.

# relevant options:
#   --smart-case   = if set, ignores case unless the search term contains any upper case
#   -A             = context lines to show (after match)
#   -B             = context lines to show (before match)
#   -C             = context lines to show (before and after match)
#   -G             = only search files that match regex
ag jQuery -G "\.js$" -A 3

# or if you want to search all files... it is fast enough it likely won't matter!
ag jQuery -A 3

To install, I'd recommend one of the following:

• Windows?
  • Check out Krzysztof Kowalczyk's pre-built binaries
• OSX?
  • Install homebrew
  • Run brew install the_silver_searcher
• Linux?
  • See main project for details

The Platinum Searcher (pt) (cross platform)

The final one I'd like to share is the Platinum Searcher (pt). It is very new, only having been released in early 2014. It is unique in that it is the only one written in Go. Go is nice in that it has the performance characteristics of C while also being cross platform. Per the project site, it can search just as fast as ag.

You may notice that the command line options are almost identical to ag, which is nice.

# relevant options:
#   --smart-case   = if set, ignores case unless the search term contains any upper case
#   -A             = context lines to show (after match)
#   -B             = context lines to show (before match)
#   -C             = context lines to show (before and after match)
#   -G             = only search files that match regex
pt jQuery -G "\.js$" -A 3

# or if you want to search all files... it is fast enough it likely won't matter!
pt jQuery -A 3

To install, you can just grab one of the pre-built releases or run brew install pt on OSX.

What do I recommend?

Today, you have a lot of options with which to search... I'm not even going to try to mention all of the options you have if you include GUI tools! I do have my favorites, though.

You might think I'd stick with Find-String given that I wrote it, but you'd be mistaken. I definitely keep it around, but my go to at the moment is pt. Thus far, it is the fastest tool I've found at searching and it works across every OS I use. I still fall back to Find-String in some cases, because I like having PowerShell and objects in the pipeline, but for straight digging through code, pt wins hands down.

If you spot any inaccuracies or have other thoughts, let me know!

Code reviews... but random

So we were all on board with a more fully featured code review... but whose code would we choose? We weren't exactly getting volunteers left and right to offer up their code... probably because they knew that everyone else would find some reason to skewer it. After all, no code is perfect... there is almost always room for improvement.

Another problem with volunteered code is that it would typically be code that had been seen recently. New code tends to be of higher quality than legacy code; however, we have plenty of legacy code that could be greatly improved by having the team take just 10 minutes to look over it.

The solution was a PowerShell script that I whipped together in about 15 minutes. Here it is:

param (
    $fileType = "cs",
    $directoryToSearch = "c:\path\to\source\repo"
)

$scriptDir = (Split-Path $MyInvocation.MyCommand.Path -Parent)
$editor = 'C:\Program Files\Sublime Text 2\sublime_text.exe'

$excludedFilePaths =
    '\.Designer\.cs',
    '\.generated\.cs',
    '\\Service\sReferences\\'

function notIn($lookFor, $toSearch) {
    foreach ($toExclude in $toSearch) {
        if ($lookFor -match $toExclude) {
            return $false
        }
    }
    return $true
}

function allFilesOfType {
    ls -filter "*.$fileType" -recurse |
        where { notIn $_.FullName $excludedFilePaths }
}

Push-Location $directoryToSearch

"Drum roll, please..."

$randomlySelectedFile  = allFilesOfType | Get-Random -count 1 | select -expand FullName
& $editor $randomlySelectedFile

Pop-Location

As you can see, it is pretty basic. Most of the complexity involves excluding Designer or generated files. Once the script determines a random file, it opens it in a text editor for the team to view. From there, we began looking at it as a team and calling out issues... "we should use var here," "can we rename that variable?," "I think we need to dispose of that object," etc. In a short 15 minutes, we as a team were able to find all sorts of minor issues with the code.

Team Learning, Team Dialog, and Decreasing Technical Debt

By reviewing the code together, it allowed us to share the learning about what we as a team thought made for quality code. Often while pair programming, these discussions come up, but they were only between 2 or 3 at most... by doing this together, we could all benefit from the discussion.

Another benefit is that it forces us to become familiar with random parts of our system. I'm confident that almost every development team has some aspect of the "Train (or bus) Problem" as I call it... if someone on your team were hit by a train (or bus), could the rest of the team pick up without them? If not, then there is a potential liability there. By reviewing code as a group, the team can become familiar with the code together.

From a technical debt perspective, we now have another tool in our arsenal that we can use to slowly improve code. Ideally, if we continue improving our core code in this way, in six months or so we'll have trouble finding issues. We might have to go after specific sections of our code to review at that point. Either way, we've got something started that seems to be very beneficial.

Leave a comment if your team does something similar.

How old were you when you started programming?

I didn't write my first "Hello World" until I was 18 in COMP 170. I created my first personal website when I was 15 I think, but my primary tools were Netscape Composer and Paint Shop Pro. :-) I think I had figured out by that point some very basic Javascript, but I really had no idea what I was doing.

How did you get started in programming?

I remember when my dad got a new PC with Windows 3.1 on it. Prior to that, I knew how to 'cd' between directories and how to run 'dir'. All of these commands were, of course, to get to the directory where my games were installed. :-) I never really stayed in Windows at the time, because all the games were still DOS-based. I didn't really have much to do with Windows (except for the Hot Dog theme), until Windows 95 came out. That's when I started becoming more of a computer enthusiast. I remember troubleshooting Dial Up Networking so that our 14.4 modem would connect up. I also remember buying my first piece of hardware, the 3dfx Voodoo card.

As I mentioned, I started doing some basic web pages when I was in high school. This was the time of animated GIFs and tiled backgrounds, if you're interested. This was also back when 56K modems first came out and there wasn't yet a clear standard on how 56K modems would talk (you could either go with US Robotics or the cheap brands) and I worked as tech support at a local ISP. It wasn't hard to do tech support because I had been troubleshooting my own Dial Up Networking problems for a few years already.

Coming from a tech support role, I didn't really have any programming knowledge. I knew how to build a computer and I even knew about msconfig, but programming??? Nah... not really. Just WYSIWYG HTML.

When I graduated high school, I either wanted to be a musician or work with computers. Seeing as how I didn't really want to teach high school band, I decided to go to school to learn about computers. I didn't really know what Computer Science meant, but hey, my grades were pretty good so why not? So, I chose a major of Computer Science and the rest is history.

What was your first language?

Unlike the rest of the programming populace, my first language was actually not BASIC, but C++. I didn't actually write a line of BASIC until my junior year of college! I would say that I currently prefer C# over VB.NET, but it has more to do with terseness than it does with braces. For the same reason, I'm a fan of Ruby as well.

What was the first real program that you wrote?

Are you saying Hello World doesn't count? C'mon!

I'm going to define "real program" in this case as something that I could show my parents. I couldn't show them "Hello World" or a command line application to create a binary search tree because they couldn't relate to it. However, I could show them a GUI maze application that I wrote in Java. It had four players (one of which could be human controllable) and then each player raced to get to the exit. I also wrote a Solitaire program in C++, a networking Tic Tac Toe game in C++, and a Paint program in C++ (using the Windows API).

My first team application, like Brian's, was created in the capstone course at Harding. We wrote a version of Othello that had to be networked with an AI. I wrote the networking code in C#. It even had threading code, which of course was written completely wrong. I'm still not entirely convinced that I can write threading code correctly today. :-)

What languages have you used since you started programming?

In college, I primarily used C++ and C#, but I also had some exposure to some Assembler, Java, VB.NET, Perl, and even LISP! My work experience includes a (thankfully short) period of COBOL and JCL on an IBM mainframe, but primarily has been in VBScript (both classic ASP as well as scripts), Javascript, PowerShell, C++, C#, and VB.NET.

In my personal projects, I've used C#, VB.NET, JavaScript, PowerShell, PHP, Python, and Ruby. I'm sure I've missed something in there.

What was your first professional programming gig?

I got hired out of college to work at Data-Tronics, Corp. where I still am to this day. My role has changed significantly now, where I'm trying hard to push out 40 years of IT practices with more modern methodologies (down Waterfall, down!) and technologies (down Mainframe, down!).

If you knew what you know now, would you have started programming?

You bet. I'm a geek to the core.

If there was one thing you learned along the way that you would tell new developers, what would it be?

I'd have to agree completely with Brian - get involved in the community. Do not let programming become just the job you perform. Like JP, get passionate about developing. If you don't enjoy what you do, there isn't any point in doing it. Start reading blogs and going to user groups. You'll be overwhelmed at how much you didn't know, but remember that no one else knows it all either. We're all learning together.

What's the most fun you've ever had... programming?

I can't think of any one specific instance, but I think one of the best feelings is, after having spent literally hours trying to debug some problem and then giving up and going home, waking up the next day and having the light bulb come on with the solution to this problem. I love solving problems with software.

Tag, you're it!

Colin Neller, come on down!

Randy Walker, you too!

I've got other tags if anyone else is interested. I might even give some out!

I know what you're thinking - looks like David here decided to learn Ruby. I mean, that's what everyone is using, right? Ruby and Ruby on Rails? Nahhh, I'm actually learning Python! Probably the key factor for me was the Python Challenge. I follow MoW's Powershell blog and he's started up a series on working through the Python Challenge using Powershell. I had heard about the challenge before, but hadn't really looked into it much, but this was enough to prompt me to get over there and try it out. (I am planning on still learning Ruby, though - I'll just go through the challenges with Ruby later)

I resisted the urge to try to find an IDE for Python and just code it up in a text editor. It has forced me to get more familiar with the syntax as a result. The Python site has a great tutorial for starters as well as some good documentation on the available modules. The hardest part for me is to not write the code like I write C# or VB. For one of the challenges, you have to take a given string, a given mapping, and then translate the string to get the instructions to move to the next challenge. I wrote a basic loop over the characters in the string, converted them to their ordinal values, performed the translation, and then converted them back to characters. It worked, but it wasn't the best way to do it in Python. Python provides this great function called string.maketrans. Also, the map function is amazing. It is sort of like the List<T>.ForEach method except that it reads a lot better (though lambda expressions in C# make it a little better). I'm starting to understand the power behind the whole map/reduce idea that Google is so big on. List comprehensions are really cool, too.

Anyway, so far, I'm to the 5th challenge (with some help from Google, the Python tutorials, and the challenge forums at times) and it is pretty cool. One of the most enlightening things about going through the challenge is that, as you complete one, you can go look at submitted solutions on the wiki. It is a great way to evaluate if you solved the challenge the "right" way or not. It is a great learning experience. One way I'm trying to apply this knowledge is that I'm running the challenges in both CPython (Python that runs on C, the standard I think) and IronPython.

Another thing I've done to try to see how other development communities work is that I've installed Ubuntu 8.04 (the alpha) on my laptop. I'm now dual booting Vista x64 and Ubuntu and it is pretty nice. I have two favorite things about Ubuntu so far - the ridiculous customization that you can do with it (compiz is amazing) and the package manager. Seriously, the fact that you don't have to pull up a browser to download apps and install them is a massive plus over Windows. In fact, you can just run a simple apt-get command if you want. Don't worry, though, I'm not planning on switching from Vista anytime, soon. Ubuntu is great and I'll be keeping it on the laptop, but I still like Vista, too. Right, right, blasphemy, I know. They're both great operating systems as far as I'm concerned. One takes an entire DVD and seems like a resource hog (not as bad anymore) and the other fits on a CD and requires editing conf files, downloading "restricted" drivers, and sitting at the command line to get video and wireless working :-) Seriously, neither are perfect. It has been nice seeing both sides of the fence, though.

At the time, I was pretty annoyed with it, because this individual was bragging about something that I considered "the wrong way to do it." In retrospect, this probably was the wrong response. Why? Because he was proud of some of the code he had written. He actually cared about it enough to not just treat it as something to toss off on to someone else when he moved to the next project.

The projects that have turned out best that I've worked on the ones where I was really proud of the code. That doesn't mean I did it the right way. I'm thinking of one example where I wrote this crazy elaborate dynamic menu system in JavaScript. It even worked in both Firefox and Internet Explorer. It had a full blown object model and made use of closures and more - it was great. Here's a complete example of usage of the menu:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
  <head>
    <title>clsNavBar</title>
    <script language="JavaScript" src="clsMenu.js"></script>
    <link href="styles.css" rel="stylesheet" type="text/css" />
  </head>

  <body>
    <script language="JavaScript">
      var nav = new clsMenu()
      nav.setContainer(document.body)
      nav.setXMLUrl('NavBar.xml')
      //nav.setHorizontal(false)
      nav.buildMenu()
    </script>
  </body>
</html>

It had one problem. Maintenance. Maintenance on the system will be nigh impossible for the next guy. From the very beginning, I should have used CSS for the entire menu structure. When and if someone ever decides to change the way the menus look, well... good luck. However, it was still a good experience. I learned more about the inner workings of JavaScript from working with that than I did from any blog post or book I've ever looked at. I would have never learned what exactly 'this' references in JavaScript without that example (see this post on JavaScript gotchas and refer to the section on 'this').

In all of this, I have learned to be very careful of the code I'm proud of. Inevitably, if you're growing as a developer by "sucking less every year," you're not going to be too proud of your code in a year or two anyway.

Do you have any code you're particularly proud of? If it turned out to be the "wrong way to do it" but you learned a lot from the experience, you get bonus points.

I completely and wholeheartedly agree with his comments on the general lack of knowledge that developers have regarding real OOP and software design concepts. Many of the developers I work with are terrified of the upcoming releases of the .NET framework. The thing is, they're just new releases in tools and libraries. Sure, they provide value - I don't know how many times I realize that some UI I'm trying to work with in WinForms would be ridiculously easy to build in WPF. And WCF does a great job at abstracting the goo that connects all of my objects. However, if I don't have a good background in solid OOP design and separation of concerns, WCF won't help me at all anyway. These new tools aren't going to do anything to make me a better developer. I'll still be able to write awful code.

I commend these guys for trying to get to the heart of the issues in the .NET community and I hope that the solution isn't to just move to Ruby and Ruby on Rails. My opinion is that we have to fix the problems in our community - if we just migrate to another community, the problems and lack of knowledge will eventually follow us. I can still write bad code in Ruby, too.

Being one of the guys who won't be able to make it, I have a few requests. I would really like to see the content from the conference posted online or made accessible to those of us who won't be able to make it, particularly considering the fact that the conference sold out. Microsoft did a good job in posting content from both MiX and TechEd this year and I think that would be a welcome addition from this conference as well.

Keep pushing this knowledge out - I'm optimistic that things will improve.

This post has a few goals:

1. I want to gain a better understanding of where I stand regarding testing code.
2. I want to share some of these ideas with others, particularly my coworkers, who might not have encountered ideas like unit testing.
3. I want to get your input on this and see if anyone else struggles with these issues, too.

Here are the different thought processes that I've seen regarding testing:

No Testing (i.e. did it compile?)

This one's easy to categorize, right? Basically, no testing happened whatsoever. If it compiles, you're set. If you're working in a dynamic or interpreted language, then good luck. Hopefully, you've never seen this one before, but I wouldn't be surprised if you have.

I have a horror story to share regarding this. A few years ago, my team was on track to install a fairly substantial update to a daily scheduled application. The update unfortunately required some changes to the script that kicked off the whole process. Because my team didn't own this script, we had to get someone else to do it. What we didn't know is that a certainly individual who will remain nameless decided to convert this script from REXX to VBScript. This would have been a good change at the time, had we prepared for it. Needless to say, this wasn't even the worst part.

This individual never even attempted to run this script.

You heard me - this individual converted a script from one language to another one and never tested the script at all. How could I possibly know this when I didn't even know the script was being converted? Because when the script was scheduled to run the next day, it blew up. It blew up because of invalid syntax. It blew up because there was VBScript code at the top... and REXX script at the bottom. I spent the better part of two days attempting to fix that problem.

The lesson here is to at least run your application once before installing. I don't care if you're the best developer in the world. You can still make mistakes.

Don't do this.

Manual Testing (i.e. F5 testing)

Manual testing is when developers run their application and attempt to test all of the functionality themselves. If they don't spot any problems, then the application is ready for production.

I used this technique the most while in college. If my professor could break our application with invalid input, then our grade would drop. For each problem the professor found, the grade would continue to drop. The majority of the applications that I wrote during this time were command line applications, so most of the user interaction was pretty easy to verify. I missed a few edge cases sometimes, but I was able to test the basic functionality because the application itself was so simple.

I consider having someone else test your application an example of this as well. My experience is that usability problems are discovered here instead of bugs. The problem is that most developers have their own projects to work on, so testing your application isn't exactly at the top of their list of things to do. In other words, their testing will likely be even less rigorous than your testing.

Manual Unit Testing

This is a small variation on manual testing the whole application. At this point, you are testing smaller units rather than an entire application, which is a good thing. To do this, you typically have either a command line interface, a small form or a small web page that uses the small unit from your application. Your UI likely performs a few actions on your library and you then examine the results for problems. Sometimes, you'll enter a few input details to test different scenarios. Ideally, you'll test as much of the functionality that the library provides as possible.

The most common place I see this is when someone has written a shared component or created some external assembly that will potentially be used by someone else. It doesn't have a UI of its own, so to test it, you have to create something else to run it.

On the testing continuum, this is the first case where application testing is broken up into pieces. Developers can test parts of the application separate from the rest. As a result, there is less to distract developers.

Unit Testing

The problem with manually testing units of an application is that verification of the results is still dependent upon the developer. Everyone makes mistakes so it is only a matter of time before someone misses a problem. Unit Testing takes the last approach and expands upon it by letting the computer decide whether or not your library is working correctly.

With a manual test application, you simply look at the results that your test UI provides. Why not put those results (expectations) into code? The test can then be much more precise about its results. For example, it is much easier to determine if a returned numeric type is an integer or decimal value from code than you can from a UI. In .NET, you can just check the type. Better yet, you know immediately from code whether or not that is a "0" or an "O".

These tests provide value during development time, but particularly during maintenance time. Imagine that a user of your system decides that they want to change something. Crazy, right? Have you ever made a change to an existing system and then broken existing functionality elsewhere in the application? This is why regression testing is necessary. Unit testing makes regression testing even easier because the list of tests you have stays with the application. As you find new bugs, you can write tests for those so that they never show up again.

Tool support for unit testing is awesome, too. With tools like MbUnit, NUnit, TestDriven.NET and others, it is easier than ever to write and use unit tests. The tools get better with each release, too. One of the things that is nice about the unit testing libraries available is that they all have test runners that generate reports. This allows you to automate the testing and tie it into your build process or test your code nightly or whatever. That is one of the ideas behind Continuous Integration. Every check-in of an item into source control results in a build script running which can also run tests. Not only do you find out if you broke the build, you also find out if your tests now fail.

One of the problems that people have with unit tests is that they feel like they spend twice as long on code because they're writing tests in addition to the code that will run on a user's machine. Doesn't that increase development time? In my experience, it adds to the time (though not twice as long) of the first iteration of software development, but it can significantly cut down on latter iterations. Have you ever maintained legacy code? I hate working with legacy code because half the time I end up breaking existing functionality. With unit tests, when I later have to come in to change a program, I can feel confident knowing that I'm not breaking existing functionality.

Test Driven Development

How about writing your unit tests first? That will blow your mind the first time you think about it. The idea behind Test-Driven Development isn't so much that you're writing a test first as you are designing the contract for your class from the outside. Proponents of test driven development very often state that this development methodology helps drive their design more than providing a good test framework. The test framework is an added benefit to good and extensible design.

This is the hardest of the thought processes behind testing to really grasp, at least for me, because it requires a change in the way you think about developing software. Some don't see the benefits from it and others wouldn't program without it. I certainly can see the value in it, but I haven't had enough real world experience actually doing it to be effective with it yet.

So, did I miss anything? Where are you on the testing continuum? I find that I move back and forth between Manual Unit Testing and Test Driven Development. I'd like to move more towards <acronym title="Test Driven Development">TDD</acronym>, because it is certainly beneficial and I find that code designed with testability in mind is much easier to modify later.

One thing to remember is that all of these ideas play a part in testing an application... except for the not testing idea. At some point, you'll need to actually run your application to try it out. If you employ unit tests, they'll simply provide more confidence in the application and provide future insurance when the code changes - and it will change.

For more information, check out this software testing article on Wikipedia.

One of them is Martin Fowler's Refactoring, which I'm really looking forward to. I've started ASP.NET MVP Hacks, which is pretty good. I'm only up to chapter 3 or 4, but I've already seen a decent overview of the provider model that ASP.NET uses.

At work, John Robbins' Debugging Microsoft .NET 2.0 Applications and Bruce Payette's Windows PowerShell in Action are sitting on my desk. I haven't yet started the PowerShell book yet, but I've gotten a little ways into the debugging book.

I just read a funny story that John Robbins provides in his debugging book about having what-if sessions during the project planning phase. He notes that in his prior job as a member of the Green Berets, they would have what-if sessions to plan for any and all contingencies. They're lives were on the line after all.

He pointed out that, after moving to software development, he could get his development team really uncomfortable by asking what-if questions like, "what if Bob dies before we get through the requirements phase." I'll have to remember to ask some "what-if-death" questions at my next team meeting...

The survey itself didn't seem particularly helpful, but the questions it poses do help in enumerating many of the problems I've experienced by actually putting them into words.

It also is beneficial to me because some of these mistakes stem from the developers instead of the management. I've been guilty of developer gold-plating and the silver-bullet syndrome many times, which is likely a result of being a beta junkie. We're in the process of moving to .NET 2.0 (no, not even .NET 3.0 or 3.5 yet) and I'm already jumping to move to Visual Studio 2008 (formerly Orcas). I mean, surely WPF, Linq, and WCF would solve all of our problems wouldn't they? Or, if we suddenly went 100% with Test Driven Development, all of our problems would disappear! Wouldn't they?

Sam Gentile's comments on writing maintainable code are very relevant to silver-bullet syndrome. He points out that the XP methodology revolves around 12 practices and not TDD by itself. TDD isn't a silver bullet but instead is a tool to help document and protect your codebase. You also have to work at refactoring your code and keep it clean and simple.

I haven't ever worked in an XP/Agile environment before, but I do like the goals that it strives for. I'm really pushing my team to learn more about architecture, design, and unit testing because I really do see the value. We really have to just start using these tools. Otherwise, we'll keep talking about them and never actually do anything.

Thank goodness for all these tech blogs. I've learned more from reading these in the past couple of years than I have from just about anything else. It's almost like I'm being mentored by all of the more experienced developers.