TDD is BS?

Nick Sabalausky SeeWebsiteToContactMe at semitwist.com
Thu Jun 20 15:11:02 PDT 2013


On Thu, 20 Jun 2013 03:15:54 +0200
"Chris Cain" <clcain at uncg.edu> wrote:
> 
> Personally, I'm a big fan of TDD in general, but I think it's one 
> of the most often misunderstood things in the field of 
> programming. It's like if you ask a group of religious people to 
> define what their deity wants from them... everyone's going to 
> have a different response and everyone is going to claim that 
> theirs is the "only one true way."
> 
> So, here's my "only one true way" of TDD (tongue in cheek):
> 
> [...]
> 
> Anyway, TDD isn't BS, but I do think its misused. The misusage of 
> it is (sometimes) BS, for sure.

Very interesting and helpful explanation! I don't feel somewhat unclear
about it now like I did before.

It sounds like instead of trying to come up with a better buzzword for
it, they should just call it "Design Your API First". Calling it TDD or
BDD or whatever is like referring to DRY as "Generalization Oriented
Coding". Pointless obfuscation of meaning.

I do, however, still find that designing an API before doing any
implementation is frequently premature ("Premature design", I guess you
could call it. Counterpart to "premature optimization".) Granted, I
certainly agree it's often good to give at least some up-front thought
to API and overall architectural design. But in my experience, the
amount of up-front design is something that needs to be judged on
a case-by-case basis, and the "right amount" for a given task will
likely be different for every programmer.

I've found that trying to do a detailed API design up-front is usually
(not always, but frequently) a very bad ROI. It can easily end up taking
a fair amount of effort (since there's so many unknowns at that point),
and then most of it ends up needing to change anyway (since it's based
on so many unknowns), which renders anything more than a rough up-front
analysis wasted effort.

What usually works much better for me is to first get something
*working*, and *then* look at the API from a user's perspective and
think "Ok, what's wrong with this? Can I improve this?". At that point,
refactoring the API into something better tends to be much more
straightforward since I'm dealing with a real working "thing" rather
than designing in a vacuum.

Granted, there have definitely been times where I did feel it was
prudent or necessary to do a more detailed up-front design. In those
cases, I certainly do so.

And than sometimes "getting something working" is just simply more
important than worrying about an ideal API. So again, it's all a
case-by-case judgment call.

I don't really feel that "Design Your API First" is really a
*generally* correct thing for most cases and programmers. To me, that's
kind of like saying "Strings are better than integers" or "Integers are
better than strings". It's just too dependent on the given situation.



More information about the Digitalmars-d mailing list