The Start-Up Trap
blog.8thlight.com
The Start-Up Trap
1–10 of 145 posts
Re: The Start-Up Trap
#2I 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 for not using it. But unless you are the one in their shoes, you will not know the whole of their reality.
In a perfect world I'd write tests for everything. In the real world, I write tests for almost nothing. Most of the work I do is on stuff that might be gone tomorrow.
Re: The Start-Up Trap
#3Re: The Start-Up Trap
#4Why do so many TDD people think that people who don't use TDD don't write tests?
Re: The Start-Up Trap
#5Great, 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…
Re: The Start-Up Trap
#6Great, 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…
So rather than having to make a change, run up the app in my browser, and manually test that the latest bit of code is working, I can test individual functions just by running my unit tests.
Of course this doesn't obviate the need for browser based testing too - but it can reduce the amount of it you need.
TDD allows me to produce working code faster by helping me notice and fix my errors sooner. If you're an excellent coder, maybe you don't need this- but I certainly do!
Re: The Start-Up Trap
#7In the very earliest days of a startup, you can easily hold the entirety of the problem space in your head. Refactoring is simple, tests or not. I can destroy and rewrite a feature from scratch in hours or days. A non-trivial number of the features I'm writing will not exist in any form a week or two later. This is not a problem with process or planning; this is the nature of a startup.
I think that TDD is immensely valuable as a team and product grows, but claiming that your startup will fail because you aren't applying engineering "best practices" from day 1 is counter to most successful startups I've worked with.
Re: The Start-Up Trap
#8That's some serious strawman. In between 0 tests and TDD, there's a lot of room to maneuver.
Re: The Start-Up Trap
#9TDD has its place, as most all main-stream methodologies do. But, lets just admit that the people that use this methodology are in the minority. The rest of us are working on smallish projects that are struggling to be worthy of the time-budget that they've been granted, and we're more worried about shipping than caring about how not having TDD in place will slow us down in phase III. Assuming phase III ever happens. We're using all the best-practices we can, but TDD doesn't rise above the bar most of the time.
Re: The Start-Up Trap
#10So yes, its foolish to skip testing. And yes, the race goes to the foolish.