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.