Avoid DRY for Product Development

I can't disagree with that nonsense enough. When he refers to polish, he is referring to code which he has already thought out which will eventually not be repetitive, so applying DRY is easily dismissed as not applicable in that instance. Applying DRY never usually means that you will create branches, etc. You do that if you are writing modular code. The whole point in DRY is that you do not repeat yourself. Good OO DRY code never commonly suffers the need to do what he is describing. Writing DRY code is actually faster than copying and pasting whole chunks but only if you have a very good understanding of the code. A good reason I can see to not use DRY techniques is if you do not have the skill level required to write DRY code because you are unfamiliar with an included library of classes for instance.

As far as scrubs, he's referring to someone as doing a job which he thinks he is above when it would benefit his project if there where many eyes on the same thing instead. If he understood his libs and tools well enough, he wouldn't need a "Scrub." What use would they be anyway if they are new to the language? How are they going to spot that cross site scripting hole you've copied and pasted five times everywhere? Most people doing the job which he describes make a poor effort because it is well known that developers who are not adding new features are largely disinterested in their work.

My point is that if you learn properly how to write DRY code, you avoid large fixes that involve searching through the entire code for particular strings. If you use OO DRY techniques, your fixes are in one place and are made quickly. There is nothing slow about writing DRY code and very few real disadvantages (None of which he has pointed out.) So if you learn to write DRY code properly you should see your development time slashed by sometimes by as much as three quarters. You will also have considerably less code to maintain.

It's nothing personal. My experience tells me that he is yet to use DRY techniques correctly and if he needs a "Scrub," to tighten up the code, it is almost always faster to just re-write the entire project using DRY techniques instead. If you write code and then try to make it DRY, you have completely misunderstood the point of DRY.

I'm all for going just what needs to be done, but I think you are not giving good advice about "hiring scrubs". I worked for a successful company that had a younger less experienced developer write the original code. But he was not a "scrub". His code could have easily have been written by another developer with a few more years experience. Yes, he made some rookie mistakes in the code, but it worked and was close enough to keep the company going.

However, you often get what you pay for, and that goes for both hiring inexperienced developers and offshore/contracted development.

If you do hire young/inexperienced, make sure they have a mentor that enforces good practices or have code review/are pairing and that these developers seem to be learning good practices.

There is a difference between bad and "good enough".

Going in with this attitude is not good at all. I'd say don't become obsessed with DRY, because in the beginning it often won't be clear when it's appropriate to "fork" portions of the code versus adding a branch or two to the core logic. But if you go in with the idea that copy/pasta is the way to write code then you'll have important logic spread across dozens of places and it will become a nightmare to make what should be a simple change.

It's a cost benefit tradeoff, but I still think far, far more people routinely underestimate the costs and overestimate the benefits than the other way around. In all the major systems I've worked on in the past five or six years, I've always gotten serious leverage making sure I'm working DRY, and thus able to do more with less, and in particular these past three years have A: involved me doing a project where if I had adopted this mindset it would have failed in the worst way possible, initial modest success followed by endless soul-sucking failure brought on by code debt brought on by DRY violations, and B: having the worst part of my day-to-day coding (and, correspondingly, the most expensive part for my employer) being the part where I have to deal with a large mass of non-DRY code. In fact my current project is basically replacing a clusterfuck brought on by a system that adopted the recommended approach quite extensively.

In my admittedly limited experience, non-DRY code still has huge costs that are easy to gloss over at first and a benefit curve that curves down way faster than anyone would like to admit. In many cases people can't even see how fast the curve is trending down because they've never even seen a properly-done product.... and I don't even mean "a product done to the pitch of academic perfection", I just mean a decently done product that isn't perfect, but we still put significant time into staying DRY and fixing DRY violations.

YMMV, of course. I suppose ultimately people following this advice has certainly advanced my career, as I clean up behind them...

Damn... I had a boss that wrote significant parts of a product and we could always tell that he wrote part of it because he'd repeat a 30-line block of code 7 times, rather than writing a subroutine.

There are cases where we all violate the DRY principle... Sometimes it makes sense to subroutinize something the fourth or fifth time rather than the second time. But overall, DRY is good.