March 18, 2003

And I just came across this article from Japan Times, which suggests that there is a secret, massive underground complex beneath Tokyo. The official description of the Tokyo subway is off by an order of magnitude; they claim it’s about 250 kilometers in size, while an actual investigation indicates it’s more like 2,000.

But the guy who’s looked into this – a well-respected reporter and clearly very sane man – can’t get his book on all this published. Fascinating.

Of course, we anime fans know why. The complex is clearly for the construction of the giant robot in case the aliens attack again.

I’m going to write about programming today. Abandon All Hope, etc.

Extreme Programming promises to fix lots of problems with traditional software development, using a variety of practices. I’ve recently begun implementing these practices, including Pair Programming. That’s been going well.

But one of these practices has been very difficult for me to implement. I just couldn’t get my brain around Test-Driven Development. I finally began following it last week, and it’s been an enlightening experience.

Here’s the concept: For any piece of functionality you want to implement, you begin by pretending that you’ve written a function to implement that functionality, and you write tests to ensure that the function works.

Then you run the tests. Of course, the tests fail, because the function doesn’t exist yet. Then you write the function so that the tests pass. When the tests pass, you’re done.

This felt like a backwards way to write code, and it creates a whole bunch of extra code in the form of tests. Ick. It felt wrong.

But then I looked at it from another perspective: When you write tests first, you ensure that you have tests for every piece of functionality in the application. You can prove that your application works.

(Okay, a bunch of working tests are not rigorous proof that the application works as requested, but it’s strong evidence.)

Moreover, while you’re write those tests, you have the opportunity to think about how the function should work before you begin writing the function. In fact, once you’ve written the tests, you know how the function should work. Writing the function becomes easy.

But it still felt weird. I couldn’t get past my psychological block, so I decided to just start doing it, right or wrong, particularly on easy functions.

It works. It works really well. Writing the actual function is easy, and I end up with a set of functions that show that my application works properly. Sure, the process isn’t ironclad; my “proof” is only as good as my tests, and they may be wrong.

But I’m now in a much better situation than I was when I just wrote my functions out of nowhere. And I think that that’s the ultimate indication that this works for me.

Leave a Reply

I work for Amazon. The content on this site is my own and doesn’t necessarily represent Amazon’s position.