I’ve been a Test Driven Development advocate for about 8 years now. Pretty much since I’d read Kent Beck’s book. (For those of you who aren’t developers… I’ll post something interesting later. You might want to take this time to go for coffee, have a snack or something.)
For all my cheering about it, I find it positively amazing how difficult it is to actually perform, even after all this time.
As I see it, there are three problems I have:
1) Laziness. Let me just get that out of the way so nobody thinks I’m deluding myself any more than I really am. It’s hard to do it right. Now before all the Bob Martinites jump down my throat, I know. I know ‘you have to go slow to go fast.’ I know that the amortized cost of Test Driven Development over project life is lower than the standard Jackson Pollack methodology most programmers use.
But when I’m sitting there, emacs open and I have something to do, I find it nigh impossible to avoid “just doing it.” I don’t set up my test scaffolding and start a perl script with ‘test();’ then watch it fail.
I write the code. I spend a few minutes thinking about the algorithm then I top-down it. Most of the code I write is small, a few hundred to a thousand lines at a time.
Oh I’ll create tests and I’ll mock out external I/O calls, generally with stubs that print to a log file and return predictable constants results. That’s a long way away from TDD doctrine.
But generally I write the code that does the task I need it to do and check some output, write a couple test functions in retrospect, generally for future expansion and as a platform from which I can test fringe cases.
2) The nature of the problem domain makes TDD tough.
The code in this context is very I/O bound. Most of it is simple data conversions. But ALL of it requires multiple systems, usually at least one database, at least one network connection and a couple external services. It’s very hard to write test driven code with all of those interactions. Well…let me rephrase. It’s very hard to write test driven code that centralizes on those actions. You end up with a bunch of mocks and nothing else.
Best case scenario, which we are struggling towards on a couple fronts, would have these external services canned in decoupled modules. Then, having standardized interfaces we could create mock equivalents that would provide a solid test scaffold.
I suspect though, without an automation responsible for driving the test suite that we’d never reach sufficient momentum to carry us into test sufficiency.
3) I don’t control the team or the codebase
I can’t change policy. Don’t wag your finger at me like that. I can see it. We have standards and idioms that make their own sense to the extent they’ve been thought about. But nobody’s interested in becoming an Agile/XP shop. They’ll contend that the checks and balances built in to those methodologies are for junior programmers and while I’ve avoided being outright contentious in making the point of how blatantly fucking brain dead that perspective is, I’ve gotten nowhere. But that’s par for the course. I’ve gotten nowhere in my last four positions on this particular point.
“But Mikey! Lead by example!” Well yeah. That’s a great idea; and I’m going to do as much of that as I possibly can. The problem is that leading by example means violating internal standards and generally creating a sociopolitical mess. I can’t do it in a vacuum, the software ecosystem (holy shit did I really just type that? *hurl*) is far too tightly entwined for me to venture out with my own style too far.
It is possible, I suppose, to write up a big evangelical case for Test Driven Development and present it to the team while proposing we run one or two projects that way as a trial.
I’ve noticed in a decade or so of trying to pursue XP that people…don’t seem to understand what it’s like in the financial industry. I get a lot of “well just explain it to them!” as if everybody in the company had once worked with one of those Ruby consulting firms who wear matching t-shirts at conferences (Look at us! Look at us! We’re that Agile shop! Are you looking? *SMACK*)
I’m going to use the phrase that makes Agile/XP coaches cringe:
IN THE REAL WORLD.
In the real world it doesn’t WORK like that. Now, I have nothing to say about whether it should or not. Frankly I’d love it if it did. I would. I’ve considered leaving the industry entirely because of it.
But I can sit down with middle and senior management and make the case for tracking success in development as a somewhat Machiavellian method of shining a light on the internal development organization, while having a couple suggestions for how to improve the highlighted weak spots. And sure, perhaps that would take some hold and cascade through the organization.
But it’s harder to get people to care than you might suspect. They like their panics. They like their emergencies. They like their round-the-clock support schedules and call-trees. Of course they’re loathe to admit it. But all that hand waving and running around on fire gives them the impression that something important is happening.
Look I Loved, LOVED the week Mike Hill came to the small firm where I worked six or so years ago and blew the top off my head when he supplemented my minimal TDD understanding with the full palate of Extreme Programming practices. Then the one on one time with Mike Feathers, when he showed me that unit testing existing windows GUI code was an entirely practical notion. Then Uncle Bob himself (whose time I wasted shamefully while I tried to be overly clever out of raw starstruckitude. Unfortunately if I had his time again I STILL don’t know how I’d make good use of it.)
But no matter which way you slice it, the culture of “Big Finance” just doesn’t seem interested in so much attention on the necessary evil of software development practices.
I just don’t see it working.