5 ms·

My experience is that you can write an essay like this about any development practice. You can cite your experience ignoring it, you can say some nice things ab

My experience is that you can write an essay like this about any development practice. You can cite your experience ignoring it, you can say some nice things about the importance of experience and priorities and managing trade-offs, and you can satirize people who are dogmatic to the point of becoming cult-zombies. It appears as if such an essay providing great advice. But it it? What is the reproducible, objective process or behaviour this essay is advocating? If I give this essay to five teams and then look at what they are doing to follow its advice, will they all be doing the same thing? What results does this essay suggest we will obtain from following its advice? How can we be sure it will be better than the results we would obtain from mindlessly chaining ourselves to the red/green light? For better or for worse, the red/green light protocol is specific. As such, it can be criticized. A specific protocol has edge cases. You can argue slippery slopes. It's a stationary target. Whereas, vague and nonspecific generalities are more difficult to criticize. There are no details, so how does one identify edge cases? It's great to hear about this one specific anecdote. beyond that, what am I supposed to walk away with besides the knowledge that slavishly following a process can be bad?

sturgill 14y ago
I'm not sure that there is a sure-fire way to quantify what tests are or are not necessary. In my opinion, this is something that comes with experience and is more of an art than a science. But I'm okay with that. If all you got out of the article was that slavishly following a process (like TDD) can be bad, I'll consider that a win for my writing. Because my general feel of the community is that testing is some sacrosanct practice that must be adhered to without question. And I question that. I write tests. I'm not anti-test. I just imagine I write far fewer tests than most. In my opinion we should constantly question whether a certain practice (in this case, writing a specific test) is worth it. I think that's a healthier approach to development than blind red/green light.
- trcollinson 14y ago
  I very much agree that knowing when to test and when testing is not needed is an art, not a science. I also hope that your readers know the difference between writing tests and writing code using tdd. My biggest problem with your statements comes down to the idea that you claim tdd can be bad (particularly, it would seem, for startups) and yet you do not give an alternative which has equal or greater benefits without the perceived overhead cost. You say we should constantly questions whether certain practices are worth it in stead of blindly following red/green lights. Fair. But how will questioning practices give you the knowledge that your code is not broken when a junior developer makes a change "somewhere"? How will questioning practices allow you to better refactor when you pivot quickly? I have worked in many startups and I know time is money and bank roll is king. But I believe that tdd allows you to keep those financial concerns in the black longer. If not tdd, what is an alternative method? "not writing code in tdd", is certainly an alternative one, but is it a good one?
  - sturgill 14y ago
    To be clear: I did not say TDD was bad. I simply said it might not always be best. I took that a step further and suggested that with a start-up, and especially an early stage one, is probably not worth it. Not that it's bad or wrong. Simply that the costs might outweigh the benefits. If you aren't market tested and/or market validated, I would suggest that getting something out the door is probably more important than test coverage. Because odds are those tests you wrote will be worthless when you pivot. There's a cost to writing tests, and the benefit from those tests are increased when they are reused. If you use a test once, then pivot and have to scrap it, you would have been better off hacking your way through the first release and getting to that first pivot faster. Once you start to gain market traction and you actually know what the market wants you to be then your world changes and your approach to writing code should as well. And as for junior devs, that's a tough one and a reason I avoid hiring junior talent. Not avoidable for all managers, but I didn't write my post to be the new bible. Quite the opposite: I think we're a bit too worried about making sure we're doing what everyone else says we should be doing. Rails is omasake and all... I'm just tired of hearing everyone talk about TDD as if it were a given. Protecting against SQL-injection? That's a given. Being a TDD-based web startup? Not so much.
    - rhizome31 14y ago
      The problem with articles like this is that people who don't work in web startups and aren't writing tests at all will see this and go "writing tests is hard, that guy on HN said testing wasn't worth it, therefore I'll carry on without writing tests". You seem to live in an environment where people are already advanced in their software practices, but I doubt this is representative of out industry as a whole. Your analogy with SQL-injection is quite revealing. I can assure you that protecting against SQL-injection is not a given for everyone. The irony is that if testing is over-hyped, it's not where it would be much needed. Too many big-budget long term developments don't use testing at all. Because there are no tests people are scared to make changes because it might break something, so they never refactor and the code becomes a big mess which obviously makes it even more scary to change. I felt like a hungry man reading an article about how food is over-hyped :)
  - 14y ago
- Evbn 14y ago
  If you have a general feel of the community, your community is very small. Is your community full of laptop researching prototypers, or million request per second distributed system operators?
  - sturgill 14y ago
    By "community" I'm referencing the Rails startup scene in particular, and technology startups in general. Here's a fun exercise: go find a job posting for a Rails startup that doesn't expound on the virtuosity of its TDD practices.
  - pbreit 14y ago
    "million request per second distributed system operators" is the definition of a tiny community.
    - Evbn 14y ago
      A tiny community with tens of thousands of members in each of several major cities.
seanmcdirmid 14y ago
Any popular development practice is overhyped, many of us know so little about writing good software that we often cargo cult. How does one manage a bunch of inexperienced software developers, and maybe the manager is inexperienced themselves? Well, try to copy what others say has worked! Really, the only cure is judicious/experienced application of development practice. Is unit testing always appropriate? No! Is it sometimes appropriate? Yes! But that is not an easy message for people to understand. I've seen unit tests on prototypes before because that was standard practice, only to have the entire prototype scrapped at the end...because that was also standard practice (never ship prototypes :) ). Confusing.
trustfundbaby 14y ago
> My experience is that you can write an essay like this about any development practice Right, but in this case, he's writing about testing. One would argue that relevant now because the foolishness around how to test and how often has reached ridiculously dogmatic levels. > What is the reproducible, objective process or behaviour this essay is advocating? Why does it have to have one? There are many articles that make it to HN that call out software practices that are just ridiculous and help spark a discussion about them, why can't this be one of those? why can't it be the article that makes a young developer who's slowly turning into a TDD zombie "must ... test ... everything ... all ... the ... time" pause for a second and go "hmmmm"?
sophacles 14y ago
On the other side: Today I was working with a new library. I wrote a 30 line sample program just to make sure I understood the library semantics, and that it would at least do what I thought in a situation similar to the actual code base. I called over another developer to sanity check my thinking, and he spent 10 minutes going on how I should have just written tests for it in our codebase instead. He would not take any of these as valid discussion points: * I spent nearly 7 minutes on my sample code, writing tests including the appropriate mocks for our codebase would have taken 70. * I didn't even know we would be moving forward with that library, why start integrating it into our infrastructure? * I'll write tests of our code using the library, when we figure out what the thing we're building actually does. * I would have to write that same sample program before I can even write tests, to know how to use the library. I do know now not to include that guy in my thinking process ever again, if tests aren't perfect, I will lose any time including someone might gain by dealing with his TDD is my holy saviour rants about how I should learn. Worst part: this guy takes days to write "tested" code that still doesn't actually do what it is supposed to.
- shasta 14y ago
  That guy is an asshole.
  - Evbn 14y ago
    Yet is still better in general to solidify your gains into repeatable tests, instead of throwing away all your research. To the GP, yes, the less you write tests, the more your code base rolls up into a giant ball of hair and wax, and you can't investigate the behavior of any part of it without mocking out the rest of it. That is why we say testable code is usable code.
    - btilly 14y ago
      I've been on both sides of this. You do not want to wind up with important code that is not tested. I spent hours today chasing down bugs in code that I wrote over the last month that I would have never known were there if I had not been writing tests. I value tests. But on the other hand there is a valid role for experimenting and trying things out. In that mode you're not writing production ready code - you're throwing stuff together. When you write code in that mode, following a testing mantra is worse than useless. I say worse than useless because the mental energy spent testing gets in the way of experimenting and refactoring. The right way to reconcile those two modes is to write your experimental code, think about it, figure out how you want it written, then once you know how to write it, go back and write it "for real", complete with tests. In fact the carefully tested code that I was writing today is based in large part on ideas that I figured out in a throw away prototype written some time ago, in a different language, that had very little in the way of tests.

sturgill 14y ago

I'm not sure that there is a sure-fire way to quantify what tests are or are not necessary. In my opinion, this is something that comes with experience and is more of an art than a science. But I'm okay with that. If all you got out of the article was that slavishly following a process (like TDD) can be bad, I'll consider that a win for my writing. Because my general feel of the community is that testing is some sacrosanct practice that must be adhered to without question. And I question that. I write tests. I'm not anti-test. I just imagine I write far fewer tests than most. In my opinion we should constantly question whether a certain practice (in this case, writing a specific test) is worth it. I think that's a healthier approach to development than blind red/green light.

trcollinson 14y ago
I very much agree that knowing when to test and when testing is not needed is an art, not a science. I also hope that your readers know the difference between writing tests and writing code using tdd. My biggest problem with your statements comes down to the idea that you claim tdd can be bad (particularly, it would seem, for startups) and yet you do not give an alternative which has equal or greater benefits without the perceived overhead cost. You say we should constantly questions whether certain practices are worth it in stead of blindly following red/green lights. Fair. But how will questioning practices give you the knowledge that your code is not broken when a junior developer makes a change "somewhere"? How will questioning practices allow you to better refactor when you pivot quickly? I have worked in many startups and I know time is money and bank roll is king. But I believe that tdd allows you to keep those financial concerns in the black longer. If not tdd, what is an alternative method? "not writing code in tdd", is certainly an alternative one, but is it a good one?
- sturgill 14y ago
  To be clear: I did not say TDD was bad. I simply said it might not always be best. I took that a step further and suggested that with a start-up, and especially an early stage one, is probably not worth it. Not that it's bad or wrong. Simply that the costs might outweigh the benefits. If you aren't market tested and/or market validated, I would suggest that getting something out the door is probably more important than test coverage. Because odds are those tests you wrote will be worthless when you pivot. There's a cost to writing tests, and the benefit from those tests are increased when they are reused. If you use a test once, then pivot and have to scrap it, you would have been better off hacking your way through the first release and getting to that first pivot faster. Once you start to gain market traction and you actually know what the market wants you to be then your world changes and your approach to writing code should as well. And as for junior devs, that's a tough one and a reason I avoid hiring junior talent. Not avoidable for all managers, but I didn't write my post to be the new bible. Quite the opposite: I think we're a bit too worried about making sure we're doing what everyone else says we should be doing. Rails is omasake and all... I'm just tired of hearing everyone talk about TDD as if it were a given. Protecting against SQL-injection? That's a given. Being a TDD-based web startup? Not so much.
  - rhizome31 14y ago
    The problem with articles like this is that people who don't work in web startups and aren't writing tests at all will see this and go "writing tests is hard, that guy on HN said testing wasn't worth it, therefore I'll carry on without writing tests". You seem to live in an environment where people are already advanced in their software practices, but I doubt this is representative of out industry as a whole. Your analogy with SQL-injection is quite revealing. I can assure you that protecting against SQL-injection is not a given for everyone. The irony is that if testing is over-hyped, it's not where it would be much needed. Too many big-budget long term developments don't use testing at all. Because there are no tests people are scared to make changes because it might break something, so they never refactor and the code becomes a big mess which obviously makes it even more scary to change. I felt like a hungry man reading an article about how food is over-hyped :)
- 14y ago
Evbn 14y ago
If you have a general feel of the community, your community is very small. Is your community full of laptop researching prototypers, or million request per second distributed system operators?
- sturgill 14y ago
  By "community" I'm referencing the Rails startup scene in particular, and technology startups in general. Here's a fun exercise: go find a job posting for a Rails startup that doesn't expound on the virtuosity of its TDD practices.
- pbreit 14y ago
  "million request per second distributed system operators" is the definition of a tiny community.
  - Evbn 14y ago
    A tiny community with tens of thousands of members in each of several major cities.

seanmcdirmid 14y ago

Any popular development practice is overhyped, many of us know so little about writing good software that we often cargo cult. How does one manage a bunch of inexperienced software developers, and maybe the manager is inexperienced themselves? Well, try to copy what others say has worked! Really, the only cure is judicious/experienced application of development practice. Is unit testing always appropriate? No! Is it sometimes appropriate? Yes! But that is not an easy message for people to understand. I've seen unit tests on prototypes before because that was standard practice, only to have the entire prototype scrapped at the end...because that was also standard practice (never ship prototypes :) ). Confusing.

trustfundbaby 14y ago

> My experience is that you can write an essay like this about any development practice Right, but in this case, he's writing about testing. One would argue that relevant now because the foolishness around how to test and how often has reached ridiculously dogmatic levels. > What is the reproducible, objective process or behaviour this essay is advocating? Why does it have to have one? There are many articles that make it to HN that call out software practices that are just ridiculous and help spark a discussion about them, why can't this be one of those? why can't it be the article that makes a young developer who's slowly turning into a TDD zombie "must ... test ... everything ... all ... the ... time" pause for a second and go "hmmmm"?

sophacles 14y ago

On the other side: Today I was working with a new library. I wrote a 30 line sample program just to make sure I understood the library semantics, and that it would at least do what I thought in a situation similar to the actual code base. I called over another developer to sanity check my thinking, and he spent 10 minutes going on how I should have just written tests for it in our codebase instead. He would not take any of these as valid discussion points: * I spent nearly 7 minutes on my sample code, writing tests including the appropriate mocks for our codebase would have taken 70. * I didn't even know we would be moving forward with that library, why start integrating it into our infrastructure? * I'll write tests of our code using the library, when we figure out what the thing we're building actually does. * I would have to write that same sample program before I can even write tests, to know how to use the library. I do know now not to include that guy in my thinking process ever again, if tests aren't perfect, I will lose any time including someone might gain by dealing with his TDD is my holy saviour rants about how I should learn. Worst part: this guy takes days to write "tested" code that still doesn't actually do what it is supposed to.

shasta 14y ago
That guy is an asshole.
- Evbn 14y ago
  Yet is still better in general to solidify your gains into repeatable tests, instead of throwing away all your research. To the GP, yes, the less you write tests, the more your code base rolls up into a giant ball of hair and wax, and you can't investigate the behavior of any part of it without mocking out the rest of it. That is why we say testable code is usable code.
  - btilly 14y ago
    I've been on both sides of this. You do not want to wind up with important code that is not tested. I spent hours today chasing down bugs in code that I wrote over the last month that I would have never known were there if I had not been writing tests. I value tests. But on the other hand there is a valid role for experimenting and trying things out. In that mode you're not writing production ready code - you're throwing stuff together. When you write code in that mode, following a testing mantra is worse than useless. I say worse than useless because the mental energy spent testing gets in the way of experimenting and refactoring. The right way to reconcile those two modes is to write your experimental code, think about it, figure out how you want it written, then once you know how to write it, go back and write it "for real", complete with tests. In fact the carefully tested code that I was writing today is based in large part on ideas that I figured out in a throw away prototype written some time ago, in a different language, that had very little in the way of tests.