[m0ther]

"correctness" != "correct".

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

One of our jobs as programmers, leads, or architects is to determine, of many strategies to solve a problem, which are (or may be) appropriate for the current context. Testing is done the same way; and parameters for testing are decided by the QA department. Any strategy that claims to be universally applicable (like anything labelled "clean" or "correct" or "best practices") is likely at least partially bullshit. Every problem is different, and every requirement requires special care to ensure what's being done is appropriate for achieving both long and short term goals within time allotted.

It's a given that the business already pushes as hard as they can on deadlines. If I have to cut effective quality assurance, or make compromises on what will and won't be done a maintainable or performance oriented manner to fit in meta-work that really doesn't matter; I'm going to pick a fight.

The development team has a finite bullshit budget, and the business has generally spent our bullshit budget before we get to your correctness bullshit.

The very notion of universal "software correctness" within a system of sufficient complexity is reductive and borderline offensive.

[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.