I Finally Get It

I paid lip service to test driven development for a while now. Did the same for "agile" techniques and pair programming, etc. From my last job I had a very cynical view of the way this type of environment would actually work.

Well, I recently spent a day at a little consulting shop here in the city. It was a full day interview. I went in in the morning (very tough if you've been waking up without an alarm clock for 6 months), and worked with them all day. At first I thought the way they were developing was pretty anal. I still think SOME of it is, which I'll get to in a minute. However, later in the day, I switched seats and worked with someone else. The difference in people didn't matter so much. Its just that this second task was very different. It was modifying a data structure that went across several systems and screens, and was modeled in the database, as a class data structure in 2 languages, and as xml between systems (plus, you know, screens and whatnot). This guy hadn't ever seen this code. Obviously, I hadn't either. So we start banging away, and the tests are bombing. It took a little while, but by the time we were done, all the changes were made and it really looked like the system was going to be ok. We had stuff shake out that we'd NEVER have found by manual searching. It was awesome (you know, for a huge nerd such as myself).

I admit, I was totally wrong. Great system.

I do, of course, have some things I disagreed with. They were using Velocity as their front end technology. They did this because its simple and allows testing isolation. This is where I think a dogmatic test-all approach is a little wasteful. The first task that I was referring to above was to change the display of one report screen. What they would do is build a 'gold master' screen of html from test data. Then their unit test would periodically compare that and current output to see if they match. Then, if you change the screen, write out the new 'gold master'.

I asked him, you know, what's the point? Yeah, there are possible situations where you might trip something, but I have to imagine there are ways to get a warm fuzzy from your code without all this explicit work. I was thinking if you used an IDE with some code completion for JSTL, it should be able to recognize that your accessor string no longer matches up to a property of the object you're using. I know that, ideally, the tests should be able to run on their own, but this is a situation where you're painting yourself into a corner with regards to tool choice.

However, that's not the big take away. The big point is I saw test driven development in a real project setting, and it was as sweet as the hype claims.

On top of that, I saw immediately the benefits of pair programming. As a manager, I implicitly thought it was like paying double for the same work. I now realize there are many things pair programming saves. Nobody is browsing CNN or IM friends from the office. That right there probably pays for it. You also get the obvious stuff. Less bugs. All that jazz.

When we sort out my employment status there, I'll post the name of the company and maybe I can get them some business or whatever. All I can tell you is as a manager who worked at a high stress financial company, I always thought every place was about the same with regards to real world vs. ideal. I couldn't be more wrong. This was like the Shangri-La of programming. They were very productive, but not stressed. Awesome. The biggest golf clap ever.