A useful reminder
The Start-Up Trap
71–80 of 145 posts
Re: The Start-Up Trap
#72Earlier quoted context omitted.
I don't see him have worked on any successful startups, or anything that had a good exit. Since when does one have to work on a successful startup or have a good exit to have opinions on the best way to start projects? I work at a BigCo and have started a couple of projects.
Starting projects is not the same as starting startups.
That's actually my argument. The OP talks about starting projects. The GP talks about starting startups.
Re: The Start-Up Trap
#73My feeling is that the point of this article isn't strictly to promote TDD or any single engineering tool that startups tend to eschew. Instead, the author seeks to make the broader point that cutting corners in engineering is not a good idea even in a startup . While it can make startup engineers feel like they are moving quickly relative to the competition, the engineering debt incurred is non-negligible. I strongl…
Boy, did I have to scroll down far to find someone who read the article.
I was hoping for tips about how to find a balance when other team members have bought the blanket rationale that speed trumps everything and then complain about why we spend so much time fixing bugs and fighting fires instead of working on the next thing.
Instead a bunch of reading comprehension challenged commenters are bitching about TDD again.
Re: The Start-Up Trap
#74Whilst not exclusive to TDD, I think DHH said it best: "The road to programming hell is paved with “best practices” applied too early."
And the road to failure is ignoring best practices because "I'm special" and "I'll do it later because I'll magically have time then". It's a balancing act that pithy aphorisms don't help with.
There's a reason people use the metaphor "Design Debt". Debt is a tool with tradeoffs, financial or design, use appropriately.
Re: The Start-Up Trap
#75Wait, 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 write unit tests all the time, and I don't write them first most of the time. In fact I think the advocates would have better success if they advocated plain unit testing instead of TDD.
What irritates me though is that several valid criticisms of TDD have been published (1), and in some cases the advocates (Uncle Bob included) were given an opportunity to respond, but did so poorly, or just didn't bother at all. This sends a message that they are trying to sell something.
TDD has its place, but it is not always the right tool, and it is certainly not a silver bullet.
(1) - Andrew Dalke's "Problems with TDD" may be the best criticism of TDD that I've read so far. The exchange between Dalke and Uncle Bob in the comments is also revealing. http://dalkescientific.blogspot.ca/2009/12/problems-with-tdd...
- Jacob Proffitt also wrote a classic (IMO) on the subject. http://theruntime.com/blogs/jacob/archive/2008/01/22/tdd-pro...
Re: The Start-Up Trap
#76Wait, 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…
It also felt like "selling a religion" to me. The fact is that I haven't checked on the "TDD discussion" for a while now (maybe 6 months?) and when I read the initial paragraphs and saw how confident the author was I thought that maybe I had missed something in the meantime, that probably some new studies had been published that had demonstrated that TDD did in fact provide a positive boost to the teams adopting it etc etc .
I read the whole thing but there was no mention of hard numbers. Facts were also lacking.
Re: The Start-Up Trap
#77Over the years, I've grown less and less likely to write lots of tests, after being a very large test zealot during the peak of the TDD wave. There are a few reasons. First, yes, TDD slows you down. The reason this matters is because a lot of our time as developers is spent exploring ideas, and it's pretty well understood that the faster you can get feedback on your ideas the easier it is to creatively develop them.…
I, on the other hand, have grown to love tests more and more. Not for reasons of finding bugs – though that is often a nice side effect – but because once I have decent test coverage I don't need to look at the application anymore. Being able to run the tests in the background to verify my work is sane, while I move on to the next feature in parallel, I find, is considerably faster than the code/build/review cycle yo…
I personally can't rationalize skipping the "review" part of the cycle. If it faces the customer, it's my responsibility and the luxury of not looking at it seems like trading away effectiveness for efficiency.
Re: The Start-Up Trap
#78Wait, 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…
> Having worked for over 10 years in the industry And yet you don't seem to know who the author is...
To be fair, I do not know of him either.
Re: The Start-Up Trap
#79(tl;dr: it depends) It's a hallmark of "experienced" non-dogmatic product people (UI/UX/Dev) that can use their intuition to know what are the happy paths that they need to test, what interfaces are likely to not change (e.g. a user is probabilistically always going to be a member of an organization, so unit tests around that are likely not waste), and what level of quality to introduce for a given feature relative t…
> After you prove this feature is a "thing" you want to keep around (and you've nailed down the interface), then it's a perfect time to re-write it with a much higher degree of test coverage.
I find that tests help me write things that are complete and "nailed down" the very first time.
Re: The Start-Up Trap
#80Wait, 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…
FWIW, Robert C. Martin is a talented and well-respected guy who has been writing code for more than 30 years. He has shipped plenty of working, reliable products. https://github.com/unclebob -- critique his code. I find it to be pretty dang clean. He means something very specific when he talks about TDD, and while he's certainly emphatic about it, I dont think he's wrong. He might not be right either, but he also isn…
It's when he ventures into the territory of "startups" that I start to question his experience. He's definitely talented and experienced, but it seems to me that vast majority of his experience is in consulting -- which is a very different beast than working in a startup.
I had an exchange on Twitter with him today in which I asked what startups he was involved in, and he said that he consulted for several, and then said 8th Light (the consulting firm he works at) is one. To me, that's not relevant experience.
If he wants to make the argument that TDD makes for better software, then fine. I just strongly disagree that it's worth the cost in an early startup environment.