I had an exchange on Twitter with him today in which I asked what startups he was involved in, and he said that he consulted for several, and then said 8th Light (the consulting firm he works at) is one. To me, that's not relevant experience.
If he wants to make the argument that TDD makes for better software, then fine. I just strongly disagree that it's worth the cost in an early startup environment.
I don't think doing TDD alone will make or break a startup.
But I will say this - when your startup requires 40 developers to maintain the "festering pile of code" instead of the 4-6 that should be required, you are wasting investor dollars.
When prospective candidates for employment see your code and run away from the interview, you are wasting time & money.
When your developers get burnt out dealing with that pile of crap, and your annual turnover exceeds 100% you are wasting time, money and experience.
All of these things I have seen happen, personally, at companies I worked for.
And skipping TDD doesn't help you go faster. The only timescale I've seen where it seems that TDD slows me down, is on the order of minutes. Even after working a couple of hours, I'm ahead of the game because my code works - I don't spend time with a debugger, and I won't have to do a week of refactoring next month just to add a new feature.
I suspect it comes from a combination of a) young coders more likely to find themselves at a startup, who are also more likely not to have developed TDD habits and 2) VCs, angels and the like who, while well-intentioned, likely push this notion that TDD is for "mature" companies and/or, "we'll pay that off later, just get the code out the door." Young CEOs, CTOs, founders and the like who need to validate all of their startups' initiatives and practices probably are swimming upstream if they want to go TDD from the ground up.
For some instances of prototyping and lightweight apps (like Obie mentioned), this is probably fine. In my experience though, the short term effects of playing "shipping" against "craft/testing" settle in within a matter of days and weeks, not months and years, and the mid-term effects of technical debt when a startup moves into "mature" phase (again, a much shorter time span than anyone realizes) are such that the idea of "debt" and "what are we going to do about it" becomes a/the dominant conversation on the team. I've experienced both sides.
My perspective: the cost of TDD is mainly to young coders who need to learn it and find the curve daunting. Teams built around these type of otherwise talented devs really would incur significant up-front cost to booting up a CI/Test server and getting past the curve to the point where the team is moving at a comfortable pace, comparable to where they were before implementing TDD. In this case, TDD is a very hard sell. I don't know how to solve that problem, other than changing the SV/startup culture to the point where those holding the purse strings see the benefits of craft/testing as being as attainable in the mid-to-short term as they are in the long term (and in my experience, they absolutely are).
If you have buy-in to TDD/craft (I can't really separate the two in my mind) from the top-down, and you have experienced coders that can facilitate implementing, in my opinion it's absolutely worth pursuing. The second-order effects of a culture built on these principles kick in with a vengeance right when a startup needs it: at crucial pivot points.
When you have to change your business assumptions quickly -- and this usually happens weeks or months into the starup lifecycle -- would you rather do it on a codebase where, say, your authentication/authorization and user model was tightly coupled to other concerns or not? Would you rather know with a relative degree of confidence that the changes you're making are not breaking core concerns? Wouldn't you rather do this quickly, rather than thrash around in unclear code that you'd rather just rewrite (you know, like it felt when we started!)?
And if you're pivoting, are you not more likely to be less cash-rich, under more pressure and in need of some really good success right now, since pivoting probably implies that former assumptions did not pan out the way you'd hoped? Isn't that exactly the point where you'd like to both reuse the code you need and know that things are still working around your baseline assumptions that seemed so clear a few short weeks/months ago?
I would think at this point the benefits to a startup in this mode, of a clean, fast-moving and validated codebase, of the kind that good TDD tends to produce, should be patently freaking obvious. Just my opinion.
I have been practicing TDD since 1999; and have found very few situations in which it does not help me be both better and faster at my job. I would certainly never hire anyone who did not practice it.
Again, understand that I am not challenging your overall experience or skill. I'm not even arguing that TDD is a bad practice or that testing doesn't lead to better code. I'm saying that you are ignoring the most important factor in the success of most startups: the ability to get a product to market quickly and iterate rapidly to solve problem that is not well understood.
I started a (relatively) successful startup called AgileZen in 2009. When I started developing the first version, I obsessively wrote tests. That lasted about two weeks before I deleted the entire battery.
Now, I believe that testing helps create good software. So why would I trash the tests? Because it was a bootstrapped startup. We had no revenue coming in and I was burning through the small amount of money we had in the bank. We hadn't launched our product yet. We weren't even sure anyone would give a shit once we did launch. I couldn't afford to spend time writing automated tests around code that wasn't validated from a business standpoint.
Fortunately for us, people did care, and we grew very quickly before being acquired by Rally Software in early 2010.
I am a firm believer that if I had stuck to "best practices" and maintained the tests while trying to get our product to market quickly, we may not have succeeded in the fashion we did.
This disconnect between your post and my personal experience leads me to believe what I originally said on Twitter: if you really believe that TDD is a requirement for a startup to be successful, I don't think you've ever really experienced what it's like to work in a startup.
And, for the record: I would never hire anyone who insisted on practicing TDD without enough pragmatism to consider the cost versus the value, and time the introduction of automated tests appropriately.
I would say, though, that once you reach the point where good code becomes important (and even startups face that need), TDD can help you write better code in less time with less effort. Please note the use of "can help"; IMHO neither TDD nor any other methodology will guarantee success.
By relfecting on those experiences, and many other experiences in companies large and small I have since learned a great deal about programming; and about human nature. One of my greatest realizations is that you cannot go fast by rushing. Every shortcut you take slows you down. Every attempt at cutting corners, adds more corners. And so I adopted the mantra: "The only way to go fast is to go well."
In 2002, when I started the FitNesse (fitnesse.org) project, TDD was the rule. I didn't know how well it would work, because I was very new to TDD at the time. But since the risk was low, I gave it a shot. It succeeded beyond my expectations, both as a programming discipline, and also as an open source project. The power TDD gave us (and still gives us) to keep the code clean and under control is something I'd never experienced in any other project. It was profound. It was powerful. It allowed us to go fast, and _keep_ going fast because the code stayed clean. I have come to view it as a moral imperative. No project team should ever lose control of their code; and any slowdown represents that loss of control.
I have since consulted on many projects using TDD, and have helped many others to adopt it. My son, Micah, who was the lead programmer on the FitNesse project, continued to practice TDD in other projects for clients of my company, with great success. When he founded his own company, 8thLight.com, TDD was a founding principle.
When it came time for me to start another company, (cleancoders.com) TDD was, and has remained, a founding principle. TDD keeps the code under control. That control keeps me going fast. I can't imagine surrendering control of the code ever again.
There's an old saying: "Your true beliefs are exposed under pressure." I'm glad your AgileZen story had a happy ending; but I think you got lucky. When the pressure came, your true beliefs came out, and they did not include TDD. You abandoned the discipline because you thought it was slowing you down. And now you are communicating that meme to the world at large. That's a shame.
As long as someone thinks TDD will slow them down, they will abandon it whenever the pressure is high enough. I, on the other hand, know that TDD speeds me up. So when the pressure comes, I hold to my discipline.
I know I can't convince people that TDD will speed them up. But as I look out over the industry from my rather long perspective, I see the change rolling across it. TDD was unknown in 1999. It has gained in awareness and adoption every year since that time. The momentum continues to build.
In another 10 or 15 years TDD will likely be as prevalent and important to programmers as hand-washing is to surgeons or double-entry bookkeeping is to accountants. I stand a good chance of seeing that happen.
