I'd like to share a paper I've written which teaches newbies - especially managers - about TDD.
I've written this because - as an agile convert and lapsed-programmer - although I'd intellectually bought into the idea of TDD, I wanted to try it for real before I believed in it. But it all seemed a bit daunting. I didn't have the time or skill to easily set up a development environment I could work with and then figure out how to code in a new fangled, modern anguage. So I used Excel and VBA instead. It was on my desktop - and virtually every managers desktop - for free. I didn't know how to code VBA but it wasn't hard to pickup.
The process is straightforward: I build an Excel function to do roman numeral
conversion using VBA to write the code and using the spreadsheet to hold the tests. I build the tests and code one at a time.
I first used this in front of 25 software engineering honours students and it went down very well. I ended up "pairing" with them and as a group we worked throught he process in less than 60 minutes. Pretty scary coding in front of 25 clever young things, but the tests were very reassuring. I never realised just how many mistakes I would make.
Here's some feedback I've received from various people who've downloaded it from my blog:
- I did the TDD thing today and it went over
really well. It took about 35 minutes to get to 15 fully refactored and 10
minutes for questions and discussion. I was nervous as hell but managed to get
through the code with out too many problems. I thought I was clunky in places
but one of the managers said the presentation was really slick so it must have
looked better from the outside.
All the feedback so far has been really positive. One of the other
managers said it was excellent at getting the point of TDD across. I think my boss got an accidental incite into what motivates programmers. We talked about clean,
beautiful code and how it motivates programmers. I don't think he's
ever heard off that before but many of the managers listening started chipping
in examples of their own. It was really good.
As a demo for managers I think that it
really stood up. It got the point across without losing them. I think some of
the programming was beyond my boss but the frequent switches back to the tests
kept him interested and he could see the power when I made a mistake, got
instant feedback, fix it and rant the tests again. I think 15 was enough for
certainly not the first person to recognize the value and power of TDD,
nor the first to wrestle with the problem of how to communicate this
message clearly to various audiences. I didn't know how to begin to
approach the problem until I saw the
"test drive" of TDD using Microsoft Excel
. Here was a tool for exploring TDD that was accessible to business managers!
- I like that
you've taken the TDD and separated it from heavy code. Anyone who has
fooled around with Excel can understand your paper. Well done.
Truly a sweet article: I really like it ... Very very nice. I must practice this a few times and add it to my repertoire. - Ron Jefferies www.xprogramming.com
I haven't coded for years, so please forgive my coding skill if it's not
as good as yours. I hope you find the example useful - especially if you would like to help your boss understand what it's like in your world and to get buyin to you using TDD.
BTW: My conclusion after trying TDD for real? Fantastic. I wish I'd discovered it years ago.