The Start-Up Trap • Hacker News Board

Re: The Start-Up Trap

#121

Post by unclebobmartin » Wed, Mar 06, 2013, 4:48 PM UTC

choxi wrote: post #70

megaduck wrote: post #61

Earlier quoted context omitted.

I work at one of those "contracting shops" (Pivotal Labs), and I think you're misunderstanding the reason we push TDD so damn hard: It's not about speed. It's about predictability. Good TDD forces you into building loosely-coupled code that's easy to refactor and change. When new business requirements come in, the effort for implementing them isn't increased because of your previous code getting in the way. There's a…

> "Which startups died because they got buried under the weight of their own codebase?" That's a long and very depressing list. In many of those situations, some TDD might have helped. Could you give some examples? PG doesn't include that in his list: http://www.paulgraham.com/startupmistakes.html , and in my personal experience I've never met a startup that failed because they had an unmanageable codebase.

Quite a few actually. I can name two off the top. You've probably never heard of them (why would you, they failed). Saber, and Lucid. Oh, there are certainly others. What kills them is a code base that's too tangled to manage. Estimates grow by an order of magnitude, costs skyrocket, defects mount, customers flee, investors cut their losses.

Re: The Start-Up Trap

#122

Post by thetrumanshow » Wed, Mar 06, 2013, 4:58 PM UTC

derefr wrote: post #88

j_baker wrote: post #45

Earlier quoted context omitted.

You're right. Then we'd have a passive-aggressive ding. The only thing you would have to add to make it perfect would be "...but I'd never claim the author is trying to do that."

I wouldn't even call it passive-aggressive; it's soapboxing, plain and simple. > This article is about X. But I don't care what the article says about X. I have something to say about X, and by God, I'm going to say it. --But I don't know that this is a particularly problematic thing to be happening in a threaded comment system, since people can get sidetracked by "soapbox issues" in a subthread while letting the "pa…

I concur.

There are n-ways to join in a conversation, but the more direct experience you have, the better you will be able to field certain types of discussion. So, experts and expert debaters will dive right in and attack the topic head-on. More timid souls will wait in the wings and hope that someone will say something that they can directly respond to with confidence.

Sometimes you have to be slightly shameless if you want to join in a conversation. Stating an opinion (soap-boxing) does feel a bit like cheating the system. But I would argue its slightly better than standing on the sideline.

Re: The Start-Up Trap

#123

Post by Glide » Wed, Mar 06, 2013, 4:59 PM UTC

davesims wrote: post #113

mattvanhorn wrote: post #112

Earlier quoted context omitted.

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 candidate…

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. :)

I rather enjoyed your longer comment upstream.

Re: The Start-Up Trap

#124

Post by unclebobmartin » Wed, Mar 06, 2013, 5:02 PM UTC

yannickt wrote: post #75

ardit33 wrote: post #50

Wait, since when TDD become a best practice? I know this author is advocating it, but has 0 (zero) solid data or evidence to back this assertion. He is just trying to sell another religion. What I have noticed, TDD is being pedled heavy by RoR contracting shops that just care about billable hours and not vested if the startup or company is going to make it on the long run. I see often that it is the usually youngish…

There are two things that I dislike about these articles. The first is that they ignore or gloss over the fact that there is no shortage of world class software written without TDD. I also have yet to see any great programmer preach the virtues of TDD. The second is that they blur the line between TDD and unit testing, maybe intentionally. I don't use TDD, but that doesn't mean I don't write unit tests. I just don't…

With regard to Dalke's complaints, I participated in that thread a bit; but others were doing a better job than I so I walked away. In short, Dalke's complaints were the complaints of someone who had little or no experience with TDD; and so weren't really significant complaints. Profit's paper complained more about the experimental procedure of Phil Hack's paper in support of TDD, than about TDD itself.

The reference to a "silver bullet" is a straw man. TDD is not a silver bullet. TDD doesn't keep you from screwing up. TDD will not guarantee success. But adopting and following the discipline of TDD can be remarkably beneficial, and shift the odds more towards success.

Re: The Start-Up Trap

#125

Post by unclebobmartin » Wed, Mar 06, 2013, 5:10 PM UTC

tmoertel wrote: post #40

jmduke wrote: post #15

I like to talk about TDD using a finance analogy. One of the first concepts you learn in introductory finance is that, in a mature market (ie the stock market -- basically something with a bunch of people and a bunch of information) you have to be compensated for risk . This is why a riskier stock -- like tech stocks or penny stocks -- can boast incredible amounts of risk but generally will give you higher returns ov…

> By definition, going through TDD is going to be a safe route, ... Why is TDD safe? Most TDD advocates seem to be blind to the fact that testing is a terrible way to prove many important properties about software systems, security properties for example. If you're betting your ever-so-scarce programming resources on TDD, you're probably paying too much, getting a lower return than you could be getting, and leaving s…

The safety of TDD comes from having a test suite that you trust. Given that suite, you can safely refactor the code. If you can refactor safely, you can improve the design safely. If you can improve the design, you can stop the inevitable slowdown that comes from making a mess.

What is the risk of _not_ doing TDD? The risk is that slowdown. We've all experienced it. What is the cost of TDD? You'd like to say that it takes time; but since the risk is a slowdown, the net is positive no matter how you look at it.

That's the irony of all these complaints. They assume, and sometimes they simply state, that TDD slows you down. And yet, the primary effect of TDD is to speed you up, and speed you up a lot.

Some folks suggest that it's a short-term slowdown for a long-term speedup. But in my experience the short-term is measured in minutes. Yes, it might take you a few extra minutes to write that test first; but by the end of the day you've refactored and cleaned the code so much that you've gone much faster _that day_ than you would have without TDD.

Re: The Start-Up Trap

#126

Post by unclebobmartin » Wed, Mar 06, 2013, 5:15 PM UTC

funkyboy wrote: post #49

j_baker wrote: post #13

Earlier quoted context omitted.

You're strawmanning. Uncle Bob isn't saying "If you aren't using TDD at the startup phase, you suck!" What he's saying is "Just because you're in the startup phase and think you're invincible doesn't mean you should throw best practices out the window." There are good excuses for not using TDD, and I tend to agree that "We're in a startup phase. We don't have time for this crap." isn't one of them.

Ok, then. Let's put it in another way. TDD should be used by those who can afford it. Right? I don't think many startups can, that's the point I guess.

And _my_ point was that startups cannot afford _not_ to adopt TDD. TDD does not take time, it saves time. It saves time _today_.

Re: The Start-Up Trap

#127

Post by unclebobmartin » Wed, Mar 06, 2013, 5:18 PM UTC

readme wrote: post #2

Great, more TDD evangelism. I would love to see an empirical study proving the claims made about TDD in this article and numerous others. It seems to me TDD is a huge waste of time when prototyping a minimum viable product. You want me to spend 2 hours writing tests for a feature that someone's going to tell me to rip out 15 minutes later? No thanks. It's really easy to tell others to use TDD, and even admonish them…

There have been several posts on this thread in which research papers in support of TDD have been referenced. You can find them if you simply google it. I suggest you do that.

Re: The Start-Up Trap

#128

Post by mattvanhorn » Wed, Mar 06, 2013, 5:45 PM UTC

tmoertel wrote: post #40

jmduke wrote: post #15

I like to talk about TDD using a finance analogy. One of the first concepts you learn in introductory finance is that, in a mature market (ie the stock market -- basically something with a bunch of people and a bunch of information) you have to be compensated for risk . This is why a riskier stock -- like tech stocks or penny stocks -- can boast incredible amounts of risk but generally will give you higher returns ov…

> By definition, going through TDD is going to be a safe route, ... Why is TDD safe? Most TDD advocates seem to be blind to the fact that testing is a terrible way to prove many important properties about software systems, security properties for example. If you're betting your ever-so-scarce programming resources on TDD, you're probably paying too much, getting a lower return than you could be getting, and leaving s…

It's Test Driven Development - not Proof Of Correctness. The worst thing about TDD having 'test' in the name is that people think it is about preventing bugs, or catching them.

It is not.

It is about enabling easy refactoring. The other stuff - preventing regressions, catching bugs, etc. is gravy.

Re: The Start-Up Trap

#129

Post by j_baker » Wed, Mar 06, 2013, 6:03 PM UTC

thetrumanshow wrote: post #122

derefr wrote: post #88

Earlier quoted context omitted.

I wouldn't even call it passive-aggressive; it's soapboxing, plain and simple. > This article is about X. But I don't care what the article says about X. I have something to say about X, and by God, I'm going to say it. --But I don't know that this is a particularly problematic thing to be happening in a threaded comment system, since people can get sidetracked by "soapbox issues" in a subthread while letting the "pa…

I concur. There are n-ways to join in a conversation, but the more direct experience you have, the better you will be able to field certain types of discussion. So, experts and expert debaters will dive right in and attack the topic head-on. More timid souls will wait in the wings and hope that someone will say something that they can directly respond to with confidence. Sometimes you have to be slightly shameless if…

Honestly, if your opinions were at least novel, I probably wouldn't have said anything. I've heard the same old debate many times before and frankly, it gets old. Especially when people make tangentially-related topics into being about TDD. Can someone mention TDD in a blog post without dredging up all these old topics?

Re: The Start-Up Trap

#130

Post by tmoertel » Wed, Mar 06, 2013, 6:05 PM UTC

unclebobmartin wrote: post #125

tmoertel wrote: post #40

Earlier quoted context omitted.

> By definition, going through TDD is going to be a safe route, ... Why is TDD safe? Most TDD advocates seem to be blind to the fact that testing is a terrible way to prove many important properties about software systems, security properties for example. If you're betting your ever-so-scarce programming resources on TDD, you're probably paying too much, getting a lower return than you could be getting, and leaving s…

The safety of TDD comes from having a test suite that you trust. Given that suite, you can safely refactor the code. If you can refactor safely, you can improve the design safely. If you can improve the design, you can stop the inevitable slowdown that comes from making a mess. What is the risk of _not_ doing TDD? The risk is that slowdown. We've all experienced it. What is the cost of TDD? You'd like to say that it…

The benefits that you attribute to TDD are not exclusive to TDD. They are the benefits of having well-tested code, and TDD is only one of the ways to get there.

The problem with the TDD way of getting there, however, is that it's expensive: It makes programmers see their code through the pinhole of one failing test at a time, blinding them to larger concerns, which are important. As a result, a lot of avoidably crappy code gets written at first and then must be reworked later, when its flaws are finally allowed to come into view.

If you're a new programmer who hasn't learned how to reason about larger units of logic and the relationships between them, maybe that pinhole restriction proves helpful. But for more seasoned programmers, it's constraining and wasteful.

Write well-tested code. But not using TDD.