[ctvo]

> I don't have time for distracting meta-work with questionable efficacy. My prime requisite is to deliver actual value, not dubious internal metrics.

What items mentioned in the linked post do you consider meta-work? Unit tests (TDD), types (type systems) or formal methods (to prove hard to replicate edge cases like race condition perform as expected, for example)?

The rest of your reply seems to be directed at points the post never made. Nothing was written about universality of application or that trade-offs didn't matter. The bulk of the post was how the inability of these methodologies / tools to gain traction may be because they're inconvenient... which from what I can tell you seem to agree with.

[m0ther]

In my specific case, TDD; and unit testing as religion in general. I am sure others can make similar arguments against the other two in the types of work they do. My point here is that every project is different, and that projects that do not use one or any of these techniques are not inherently buggy.

I believe strongly in manual testing and automated integration testing for the type of work I do (when executed by an experienced QA); but I have not seen unit testing save anywhere near the time or effort it requires. I am sure there are types of projects for which unit testing solves more problems than it creates, but I have not worked on that sort of project. In my experience, unit testing stops the type of bugs you wouldn't have had anyway, and doesn't do much to mitigate integration bugs (which are the vast majority of bugs I've seen). I've also seen TDD make developers overly myopic. Passing tests do however make for a conveniently reassuring metric to give to business leaders who don't care to understand what they mean or how software is built.

He/she is not narrowing to a specific type of programmer, or a specific type of programming. I am explaining why I "don't care about correctness".

Forgive me if this article is meant to be read in an academic context; I am not an academic.