3 ms·

I'm doing BDD as the lead (of 2) Rails developers at our startup, and _its the reason_ we can go so fast. Some differences we're doing from your situation: We

I'm doing BDD as the lead (of 2) Rails developers at our startup, and _its the reason_ we can go so fast. Some differences we're doing from your situation: We use Cucumber to cover the whole web app(but not flash or video processing), and only have some small rspec model specs on important methods involving billing. Cucumber coverage is also very powerful per line of test code. We have 1000 lines of cucumber covering 5000 lines of code. We aren't covering everything by tests. For example, I would have given up on the Facebook login test coverage, and just written some tests that mock a facebook-logged in user but not covered the actual login funtionality itself. If we were not doing BDD, my time estimates for each ticket would have to double because the hair-pulling debugging time would skyrocket and kill productivity. I would also hate working on a team that didn't have test-coverage because developer B might build something I don't understand or know about but I inadvertently break it and we find out 4 days later. Another benefit: we can ruthlessly refactor and tear out code because the tests immediately identify if something broke. There's also more payoff for your tests over time. The longer your project lasts, the more those tests pay dividends. Even they seem painful now, they are an investment towards maintainable code in the future. My advice: keep going with TDD/BDD and consider Cucumber for everything but your most important business-logic methods.

bdclimber14 16y ago
I agree with your points, and I think my skepticism is because most of my exposure to BDD is from purists. I worked with a developer who was pulling his hair out because he couldn't figure out how to test the SMTP emailing with gmail. We all knew it worked, but he spent a few days figuring out the test cases. A couple points though: - Ruthlessly refactoring is huge with TDD. However, I don't think there is much refactoring with bootstrapped, pre-revenue startups. Changes are generally functionality changes. - Payoff over time. With very early stage, I can imagine that shipping a day early is worth a high interest rate of payoff later. - Solo hackers don't have to worry about other developers, again at the very early stage. Overall, maybe TDD/BDD doesn't make sense for very early, pre-revenue startups, but instead should start after funding or product-market fit where you need all these things?
- ekidd 16y ago
  However, I don't think there is much refactoring with bootstrapped, pre-revenue startups. At our startup, we learned a lot during the pre-revenue stage, and twice realized that our basic architecture was stupid, wrong, and overly complex. (That was my fault, by the way.) Both times, I took 3 or 4 days and savagely refactored our product, deleting massive amounts of code. When I was done, it was much easier to make changes. Mind you, in the end, this wasn't enough to save us: We ran up against the reality of a short runway and a long enterprise buying cycle. But our product was very sweet. :-)
Lewisham 16y ago
There's also more payoff for your tests over time. The longer your project lasts, the more those tests pay dividends. Even they seem painful no, they are an investment towards maintainable code in the future. I think this is the most important thing. Tests are an investment, but once you've done them, every time you run them from that point on is free. The amortized cost keeps getting better and better. Once you pull in a Continuous Integration engine, or even turn it up to 11 and implement continuous deployment, those tests really do pay for themselves. It's just intimidating in the short-term. Whenever I've gone rogue and thought "Sod it, not today", it's invariably bitten me on the ass twice over the pain it would have been to write them.
- aquark 16y ago
  > Tests are an investment, but once you've done them, every > time you run them from that point on is free. True, but they have their own maintenance cost. When features evolve in the future you have to pay to update the tests as well. Worthwhile, but something to bear in mind.
  - chromatic 16y ago
    When features evolve in the future you have to pay to update the tests as well. Very true, but when features evolve in the future, you may have to pay the debugging costs if they evolve in ways you did not intend with regard to other features.

bdclimber14 16y ago

I agree with your points, and I think my skepticism is because most of my exposure to BDD is from purists. I worked with a developer who was pulling his hair out because he couldn't figure out how to test the SMTP emailing with gmail. We all knew it worked, but he spent a few days figuring out the test cases. A couple points though: - Ruthlessly refactoring is huge with TDD. However, I don't think there is much refactoring with bootstrapped, pre-revenue startups. Changes are generally functionality changes. - Payoff over time. With very early stage, I can imagine that shipping a day early is worth a high interest rate of payoff later. - Solo hackers don't have to worry about other developers, again at the very early stage. Overall, maybe TDD/BDD doesn't make sense for very early, pre-revenue startups, but instead should start after funding or product-market fit where you need all these things?

ekidd 16y ago
However, I don't think there is much refactoring with bootstrapped, pre-revenue startups. At our startup, we learned a lot during the pre-revenue stage, and twice realized that our basic architecture was stupid, wrong, and overly complex. (That was my fault, by the way.) Both times, I took 3 or 4 days and savagely refactored our product, deleting massive amounts of code. When I was done, it was much easier to make changes. Mind you, in the end, this wasn't enough to save us: We ran up against the reality of a short runway and a long enterprise buying cycle. But our product was very sweet. :-)

Lewisham 16y ago

There's also more payoff for your tests over time. The longer your project lasts, the more those tests pay dividends. Even they seem painful no, they are an investment towards maintainable code in the future. I think this is the most important thing. Tests are an investment, but once you've done them, every time you run them from that point on is free. The amortized cost keeps getting better and better. Once you pull in a Continuous Integration engine, or even turn it up to 11 and implement continuous deployment, those tests really do pay for themselves. It's just intimidating in the short-term. Whenever I've gone rogue and thought "Sod it, not today", it's invariably bitten me on the ass twice over the pain it would have been to write them.

aquark 16y ago
> Tests are an investment, but once you've done them, every > time you run them from that point on is free. True, but they have their own maintenance cost. When features evolve in the future you have to pay to update the tests as well. Worthwhile, but something to bear in mind.
- chromatic 16y ago
  When features evolve in the future you have to pay to update the tests as well. Very true, but when features evolve in the future, you may have to pay the debugging costs if they evolve in ways you did not intend with regard to other features.