Much of your "conventional wisdom as an anti-pattern" article rings true.

I find that many rules of thumb have suffered from being elevated to an 
annointed status, especially when given acronyms such as "DRY".  As an 
example, I might review someone's work and make a comment like "you are 
going to regret this copy-and-paste stuff". This might lead to a 
discussion of the long term maintenance implications of taking the easy 
route and might even lead to useful suggestions such as the proposed 
third-time-on-a-copy-paste warning.  If, on the other hand, I commented 
"remember DRY", well, that's it.  I have uttered an Undisputed Truth, 
and there is no need for discussion.  I have also found myself falling 
into the trap that was alluded to in the article, with an abstract base 
class that kept growing as I tried to hoist common functionality up into 
it.  I would have been better to remember another nugget of wisdom that 
doesn't have an acronym: "all abstractions leak."

Another one that bugs me is YAGNI, or You Aint Going to Need It. I 
assume that this is aimed at folks who have a tendency to over design 
things and throw in extra features that make the project late(r).  I 
have found that for big projects things are not simple enough for a 
single rule like this.  I remember working on such a project that would 
be helped by using a vendor's API to automate some things.  The API was 
not particularly well documented and was complex enough that it required 
playing around with it to figure out how it actually worked.  I had the 
luxury of a little bit of slow time between releases and decided to have 
a go at it.  I got the basic functionality working but noted that it 
would probably be better if I figured out how the error handling worked 
in the API.  I ran into the "aint going to need it" suggestion, but my 
take on it was that I did have a bit of time to research it, and I 
reasoned that by the time the project was back into panic mode I would 
realize that I did, in fact, need it, but no longer had the time to 
properly analyze it.  I have thought of various alternatives like "YMNI 
- you might need it", but decided that in the end you can't capture 
proper project planning with a one-acronym approach.

I don't follow your comments on testing.  I have found that there is 
never enough testing; you do as much as you can with the resources 
available.  I try to automate what I can - it sure helps with regression 
testing on big projects - but there is a cost that needs to be factored 
in like everything else you are doing.  Just remember that your 
cost-benefit analysis should factor in the cost of your customers 
discovering the bugs that you didn't.

> I have uttered an Undisputed Truth, and there is no need for discussion.

Agreed.  It's the same as calling something an anti-pattern.  That's supposed to
immediately settle the conversation apparently.  It's lazy thinking and something
I catch myself doing often.

> "all abstractions leak."

This one is great, maybe "all abstractions leak, eventually."

> I have found that there is never enough testing; you do as much as you can 
> with the resources available.

This one is tough, but because I work at startups with tight deadlines and many
of which don't last longer than a couple of years, all those tests amounted to hundreds
-- probably thousands -- of hours of person-hours.  In those cases where the project
died faster than regressions could surface, the only thing it did for us is make us 
"feel good" about % coverage.

I'm always on the look-out for tests that failed that actually prevented a bug from reaching
customers.  It's extremely rare.  Most of the time the change I'm making is intentional and 
also intentionally breaks the test.  This means not only did someone write a test that I 
ended up not needing, but now I have to fix a test because the expectations have changed.