4 ms·

Exactly. I think most experienced developers know about TDD, maybe they have even tried it on a personal project. But, selling it to a company that have commitm

Exactly. I think most experienced developers know about TDD, maybe they have even tried it on a personal project. But, selling it to a company that have commitments to investors, paying customers and an executive team who might not all have technical backgrounds makes TDD a hard sell. How do you explain to people who don't get it that things will take longer? One of the biggest problems with TDD is that it kind of relies on having clearly defined specifications. I don't know about you or other people here, but I've worked in a lot of places (many even called themselves Agile) where the work was not properly scoped at all. If you start doing TDD and the scope isn't clear, the goal posts keep on moving and things just perpetually take longer. I think it's all about cost in the end. It's cheaper for companies to ship buggy code and then iteratively patch the bugs. Unless they're massive showstopper bugs (which normal tests should be catching anyway), it probably still comparatively works out cheaper to fix bugs as you find them.

catwind7 6y ago
> One of the biggest problems with TDD is that it kind of relies on having clearly defined specifications That's very true. I think it's an easier sell when you have a relatively stable set of specifications (accounting software core logic) where the rate of change is low but the cost of regressions is high. But I think you can tackle the same problem space with good unit tests instead of enforcing a test-first mindset. In situations where work is vague, spending more upfront time thinking about architecture is much more useful (design docs?) imo. Having a set of units for a crappy, entangled system is pretty costly.
MockObject 6y ago
> I don't know about you or other people here, but I've worked in a lot of places (many even called themselves Agile) where the work was not properly scoped at all. I can see this argument for large-scoped scenario based integration tests, definitely. But TDD unit testing operates on a much smaller scale, that of a single patch, or a Jira ticket.
hn_check 6y ago
"But, selling it to a company that have commitments to investors, paying customers and an executive team who might not all have technical backgrounds makes TDD a hard sell" It's an incredibly easy sale. The whole basis of TDD is that it's an approach that makes your development efforts faster, with higher quality. A million graphics of the amount of time that development spends fixing errors are what sold TDD to the masses. The theory of TDD is exactly what sells to the suits and the money counters. The theory doesn't mesh with reality, though, and it's that engagement with the enemy (reality) where TDD falls down. As an aside, in my own career I've seldom been able to incorporate TDD because each project has been novel enough that trying to define tests up front was just not possible. Yes, if I was implementing the re-invent the wheel "sum two numbers" type example, it's trivial. But most of the time it's a vague API for a vague need on an uncertain technical foundation, and until the clay has taken form we really weren't sure what we were dealing with.

catwind7 6y ago

> One of the biggest problems with TDD is that it kind of relies on having clearly defined specifications That's very true. I think it's an easier sell when you have a relatively stable set of specifications (accounting software core logic) where the rate of change is low but the cost of regressions is high. But I think you can tackle the same problem space with good unit tests instead of enforcing a test-first mindset. In situations where work is vague, spending more upfront time thinking about architecture is much more useful (design docs?) imo. Having a set of units for a crappy, entangled system is pretty costly.

MockObject 6y ago

> I don't know about you or other people here, but I've worked in a lot of places (many even called themselves Agile) where the work was not properly scoped at all. I can see this argument for large-scoped scenario based integration tests, definitely. But TDD unit testing operates on a much smaller scale, that of a single patch, or a Jira ticket.

hn_check 6y ago

"But, selling it to a company that have commitments to investors, paying customers and an executive team who might not all have technical backgrounds makes TDD a hard sell" It's an incredibly easy sale. The whole basis of TDD is that it's an approach that makes your development efforts faster, with higher quality. A million graphics of the amount of time that development spends fixing errors are what sold TDD to the masses. The theory of TDD is exactly what sells to the suits and the money counters. The theory doesn't mesh with reality, though, and it's that engagement with the enemy (reality) where TDD falls down. As an aside, in my own career I've seldom been able to incorporate TDD because each project has been novel enough that trying to define tests up front was just not possible. Yes, if I was implementing the re-invent the wheel "sum two numbers" type example, it's trivial. But most of the time it's a vague API for a vague need on an uncertain technical foundation, and until the clay has taken form we really weren't sure what we were dealing with.