A blog on Agile software development and Scrum
There's a recent blog post that was sent to me in response to my insistence on Test-Driven Development:
"The Duct Tape Programmer" by Joel Spolsky.
The gist of the post is: Good programmers ship software. I agree. And my response is: Great programmers ship quality software.
When I wrote commercial software, there were no unit tests. All testing in-house was done by some internal QA testers, and if the software passed smoke tests it was sent through a full test run. This could take a week or more. The schedule was King.
When I wrote code part-time and did full-time Active Directory management, there were no unit tests. I didn't have time. I had a full time job, a rotation on the help desk, new tools to write and old tools to fix. My workload was my boss.
So if you're in the situation where just finishing is a victory, more power to you. But don't settle there and take a fanboy post to mean you never need to bother with TDD or testing in general. It could be that you constantly check in timely, buggy code that everyone else hates while simultaneously patting yourself on the back for your Duct Tapey-ness.
Today I'm developing tools full-time to be used inside of the company. There are two huge differences between intranet software development and commercial programming: Deadlines are more flexible and there is no QA department. You wrote it, you support it. For life.
Adopting Test-Driven Development and Scrum has been a survival mechanism for us. It's the reason my three person team (including myself) can support sixteen production apps. We don't dare ship bugs, our entire roadmap crashes when we have to rework.
So all I'm trying to say is that you can have your cake and eat it too. You can have good quality software that you ship quickly - just keep it as simple as possible, build quality into the process, and finish the thing.