"As for Joel’s consistent dismissal of unit testing, he’s just wrong about that. Unit testing (done TDD style) does not slow you down, it speeds you up. One day I hope Joel eventually realizes this. "
Bullshit. I call TDD more like "insecurity driven development". Perfect fit for big corps, where mistakes are punished, and being fast is not really rewarded. *hence the myriad of processes to do even simple check-ins.
There is much better ways to deal with it:
1. Design interfaces, that implement the features you think you need. That's like the outline of your essay.
2. Have classes that implement them (put all messy code there). Write your essay.
3. Do some functionality testing on the features that are important, and can reasonable be measured (.ie. no functionality testing/unit testing in UI stuff). And make sure you use it. Unit test may catch only some stuff. Proof read it.
From my experience in my previous startups, If you have to ship in three weeks, unit testing is the very first thing that gets tossed out of the window.
At the end of the day, who cares if your product has few bugs. You got to ship something. And I am saying this from experience, where a product I worked is being used by over 2million of people. Buggy? Oh yes. Did the bugs kill the overrall experience, i don't think so. If we had missed that deadline, there was huge financial ramification for the company (apart 10s millions of dollars, it was a relationship breaker with the main client). We took our time to fix some of those bugs on subsequent releases.
If we had to do TDD, we probably would have never get done in time. Sure we might have found and fixed some of the bug earlier, but none of those bugs were detriment to the whole experience anyways.
The only time you really should care to test about even the most minuscule feature, is if you are doing some highly financial/sensitive stuff.
Most starts are not in that field anyways.
"insecurity driven development" is probably a good alternate title for TDD, but instead of taking it at it's trollish face value it can generate a good analogy.
If you start walking down a dark alley - you start feeling insecure. You've got a few options from that point.
You can back out of the alley and hey, no more insecurity. A little embarrassing but you're feeling OK, you just have to go the long way round the block.
You can push on through the alley in the dark - something bad could happen or you could get through fine. You don't really know until you've popped out the other side.
Or you could carry a god-damned torch. Obviously when carrying a torch, you don't have it turned on all the time, just when you wander into darker areas where you're less sure of the environment. It lets you walk at full pace without stubbing your toe or getting mugged or whatever.
In more concrete terms: I'm a bit of a poor-weather TDDer (same with pair programming) If i start working on something that could be algorithmically challenging, cuts across multiple layers of our app, touches something scary (like our accounting code, because i don't want to lose any of our $$$), or am just plain stumped - I write a test. It fails. I make it pass. I write the next. I make it pass. I realise my code looks like ass, I refactor. The tests still pass.
I can give an actual example from this week. Our app is a large RoR app that serves multiple sites from the one codebase based on an internal DSL we have. We're in the final week of a must launch redesign (date was set because of a bunch of marketing, etc) and I get an urgent and large last minute change dropped on my desk (i'm sure you all know that feeling). I'll admit my first move wasn't to go TDD, I just went for the quick and hopeful move of quickly adding some code that looks like it should work to our DSL.
It didn't. So my very next move, knowing that I have a deadline I must hit with a risky technical change, was to start writing tests. If i hadn't, I'd have to be verifying my code works by checking around 3 different pages after a server restart which is both slow and 4 layers away from the changes. So it was faster in real time.
I'm not a big fan of TDD zealots, TDD is just another tool in the box. But TDD haters really get my goat. You're willfully shutting yourself out of a tool that can make your life easier, and help deliver code faster.
You're right, it's weird how people don't understand, don't write the kind of tests that slow you down; write the kind that help you work faster by automating the manual testing you'd be doing otherwise. Test things that you think might break, or you want to make sure won't break and skip testing the dead simple stuff where you feel it'd be a waste of time. You don't have to test everything. Seriously, if some strategically written automated tests don't speed you up, you're doing something wrong.
Bullshit. I call TDD more like "insecurity driven development". Perfect fit for big corps, where mistakes are punished, and being fast is not really rewarded. *hence the myriad of processes to do even simple check-ins.
There is much better ways to deal with it: 1. Design interfaces, that implement the features you think you need. That's like the outline of your essay.
2. Have classes that implement them (put all messy code there). Write your essay.
3. Do some functionality testing on the features that are important, and can reasonable be measured (.ie. no functionality testing/unit testing in UI stuff). And make sure you use it. Unit test may catch only some stuff. Proof read it.
From my experience in my previous startups, If you have to ship in three weeks, unit testing is the very first thing that gets tossed out of the window.
At the end of the day, who cares if your product has few bugs. You got to ship something. And I am saying this from experience, where a product I worked is being used by over 2million of people. Buggy? Oh yes. Did the bugs kill the overrall experience, i don't think so. If we had missed that deadline, there was huge financial ramification for the company (apart 10s millions of dollars, it was a relationship breaker with the main client). We took our time to fix some of those bugs on subsequent releases.
If we had to do TDD, we probably would have never get done in time. Sure we might have found and fixed some of the bug earlier, but none of those bugs were detriment to the whole experience anyways.
The only time you really should care to test about even the most minuscule feature, is if you are doing some highly financial/sensitive stuff. Most starts are not in that field anyways.