

Avoid DRY for Product Development - mathgladiator
http://blog.mathgladiator.com/2010/11/avoid-dry-for-product-development.html

======
xxxxxxxxxxxx
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.

~~~
dasil003
I agree the article isn't written well, but I don't think your response is
much better. As with all things in software engineering, DRY is a principle
that needs to be applied judiciously. I believe the OA is referring in part to
the common situation where some code can be "DRY"ed by replacing two methods
with a single parameterized method. These can be quite nuanced decisions to
make in practice.

------
devmonk
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".

~~~
smokeyj
I got a job being that "scrub" while under the direction of the lead
developer, very helpful. I was in high school so they paid me nearly minimum
wage, but I landed a salaried gig my junior year in HS. I gained the
experience needed to provide value to other companies, while subsidizing the
cost of my intern by working - a win win IMO.

~~~
mathgladiator
That's awesome. I think the company that hired you was very smart. I'm going
to write more on this, but the central theme will be about how companies
should focus on nurturing and providing opportunities to grow better talent
rather than waiting for it arrive in a nice package.

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

~~~
jhen095
I agree. Balance is key here. A bit of DRY to keep things tidy and a bit of
copy/paste to get things moving and working as quick as possible.

The company I work for has been very much anti-DRY. They copy and paste pretty
much everything and have quickly brought a working product to the table.
Funnily enough the code base is HUGE. Me, however, new to the company and
fresh out of University have been fighting the good fight and trying to
introduce DRY. However this slows down development as I refactor, and can
sometimes break existing stuff while merging two inconsistent branches.

So I have learnt to pick my battles. There is a balance. Don't fix what ain't
broke and if copy/paste will get things moving along, do not hesitate.

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

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

~~~
mathgladiator
I think DRY is very good, and I feel like many people missed the point of what
I wrote.

DRY is very engineering centric which works very well for systems (i.e. non
visual things like MySQL or node.js).

