

In Favour of Test Driven Development - rudenoise
http://joelhughes.co.uk/in-favour-of-test-driven-development

======
82unpluggd
When evaluating whether test first or test driven development is worthwhile I
would encourage a holistic approach. What is the total cost to the
organization for the development, quality assurance, deployment and
maintenance of the software? On its first release? Over its lifetime?

Carefully consider the alternatives. No testing? Manual testing? Automated UI
testing? Test second?

On the softer side (and more difficult to measure) I ask development teams how
test first affects their thinking. Do you converge on users' requirements more
quickly or slowly?

Finally, recognize that programming is a hard skill to master. TDD is another
skill on top of that one.

~~~
ams6110
I don't think that a lot of people do realize that programming is a hard skill
to master. Or at least, they keep trying to develop processes that will allow
average-ability programmers to turn out exceptional quality software (TDD and
various flavors of Agile being the current fad in this area).

Bottom line is that to deliver great software you need a solid conceptual
understanding of what it's supposed to do (i.e. good requirements analysis)
and smart people to design and implement the software. By its nature, software
development will never be reduced to assembly-line work that any warm body can
do.

~~~
auxbuss
This is an excellent and concise statement of software development. I think,
the best I've ever read.

I don't think of TDD and Agile as being fads, though, but the best we have to
date in an evolving process. It'll go on for decades yet.

That last paragraph, though, is killer: Give great input to very smart people
and it might result in a great result. Note the absence of ego.

And people, never forget that all software spends 99.999% of its life in
maintenance. Be prepared.

------
aidenn0
Is it me, or is the conclusion of the article

1) TDD is not useful for interacting with existing APIs (probably the majority
of programming today)

2) TDD works when it works and doesn't when it doesn't (which is rather
tautological).

I'm not sure that's in favour of TDD.

~~~
rudenoise
I suppose I concluded: that if the engineer has no affinity with TDD then
there is little point in continuing and practising it badly. For those who do
(or learn to), who may be in the minority, the benefits are well worth the
effort.

