4 ms·

FWIW, Robert C. Martin is a talented and well-respected guy who has been writing code for more than 30 years. He has shipped plenty of working, reliable product

by kaens 14y ago

FWIW, Robert C. Martin is a talented and well-respected guy who has been writing code for more than 30 years. He has shipped plenty of working, reliable products. https://github.com/unclebob https://github.com/unclebob -- critique his code. I find it to be pretty dang clean. He means something very specific when he talks about TDD, and while he's certainly emphatic about it, I dont think he's wrong. He might not be right either, but he also isn't lacking in "solid data or evidence to back up this assertion". http://vimeo.com/43536488 http://vimeo.com/43536488 is a talk he gave at NDC2012 that you might want to watch and ponder before dismissing the dude. He might be peddling, but he practices what he preaches while associating with people who care deeply (and publicly) about maintainable software.

nkohari 14y ago
It's when he ventures into the territory of "startups" that I start to question his experience. He's definitely talented and experienced, but it seems to me that vast majority of his experience is in consulting -- which is a very different beast than working in a startup. 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.
- unclebobmartin 14y ago
  For the record, I have been a software developer since 1970, and have worked at several different startups. One in 1976 which was a great success; and another in 1987 which muddled and eventually failed. I have started several of my own companies since 1990. I have recently founded cleancoders.com, which is a very successful video training startup using TDD for the website. I also work for 8th Light which is a consulting company started by my son 6 years ago, and is dedicated to TDD. 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.
  - nkohari 14y ago
    I don't understand how your experience at startups in 1976 and 1987, which happened 23 and 12 years respectively before you started practicing TDD, give you any information on the use of TDD in a startup environment. Consulting doesn't count, because theoretically you've sold your client on TDD's value and they're willing to pay. 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.
    - ingineering 14y ago
      TDD helps make your code better. In your case, it sounds like the key criterion was not that the code work well, but that it let you validate your belief in its business value, with the minimal possible time/money investment. I would agree TDD wasn't applicable, because it didn't provide the specific value you needed. 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.
- ToJans 14y ago
  I think Nate probably uses some other way of formalizing specs, as I formulated in my blog post here: http://www.corebvba.be/blog/post/Opinion-TDD-and-startups-you-are-all-wrong-(or-right).aspx http://www.corebvba.be/blog/post/Opinion-TDD-and-startups-yo...
- mattvanhorn 14y ago
  I have 20 years of experience developing web apps, most of which was at startups. Some succeeded despite not doing TDD, others failed despite doing it. 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.
  - davesims 14y ago
    You've said in a much more concise way what I took far longer with upstream. I can only beg off that I think my coding practices are better in this regard. :)
    - Glide 14y ago
      I rather enjoyed your longer comment upstream.
- davesims 14y ago
  This is certainly the dominant perception coming out of SV these days. But since the vast majority of startups fail and have no more time (or rather, will) to collect development metrics than they do to implement TDD, I doubt we'll ever have any kind of real validation of this perception. 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.

by kaens 14y ago

nkohari 14y ago

It's when he ventures into the territory of "startups" that I start to question his experience. He's definitely talented and experienced, but it seems to me that vast majority of his experience is in consulting -- which is a very different beast than working in a startup. 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.

unclebobmartin 14y ago
For the record, I have been a software developer since 1970, and have worked at several different startups. One in 1976 which was a great success; and another in 1987 which muddled and eventually failed. I have started several of my own companies since 1990. I have recently founded cleancoders.com, which is a very successful video training startup using TDD for the website. I also work for 8th Light which is a consulting company started by my son 6 years ago, and is dedicated to TDD. 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.
- nkohari 14y ago
  I don't understand how your experience at startups in 1976 and 1987, which happened 23 and 12 years respectively before you started practicing TDD, give you any information on the use of TDD in a startup environment. Consulting doesn't count, because theoretically you've sold your client on TDD's value and they're willing to pay. 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.
  - ingineering 14y ago
    TDD helps make your code better. In your case, it sounds like the key criterion was not that the code work well, but that it let you validate your belief in its business value, with the minimal possible time/money investment. I would agree TDD wasn't applicable, because it didn't provide the specific value you needed. 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.
ToJans 14y ago
I think Nate probably uses some other way of formalizing specs, as I formulated in my blog post here: http://www.corebvba.be/blog/post/Opinion-TDD-and-startups-you-are-all-wrong-(or-right).aspx http://www.corebvba.be/blog/post/Opinion-TDD-and-startups-yo...
mattvanhorn 14y ago
I have 20 years of experience developing web apps, most of which was at startups. Some succeeded despite not doing TDD, others failed despite doing it. 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.
- davesims 14y ago
  You've said in a much more concise way what I took far longer with upstream. I can only beg off that I think my coding practices are better in this regard. :)
  - Glide 14y ago
    I rather enjoyed your longer comment upstream.
davesims 14y ago
This is certainly the dominant perception coming out of SV these days. But since the vast majority of startups fail and have no more time (or rather, will) to collect development metrics than they do to implement TDD, I doubt we'll ever have any kind of real validation of this perception. 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.