4 ms·

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 o

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