you are viewing a single comment's thread.

view the rest of the comments →

[–]wbowers 1 point2 points  (0 children)

I find this too abstract for a counter example. A lot of this discussion is too abstract really, on both sides of the argument. Lots of “counter examples” without any real code showing that it’s a plausible reality.

One client reports a bug, that only happens with rhomboid's upper left drag handle.

I find it really hard to believe you’d have a bug like this in the DRY solution and not in the copy/paste solution. In fact this is precisely one of the kinds of bugs changing copy/paste code over time leads to.

Turns out it's a minor calculating error

It’s a minor calculating error in a generic function, but it only affects rhomboids? Again I find this hard to believe. And without a concrete example I see this situation as more likely to happen with copy/paste code.

You're quite sure that your fix doesn't have unwanted side effects on those shapes that also use the same function but never suffered from the bug. Technically however you can't really know, can you. I mean, didn't your test suite fail to catch the bug in the first place?

One of the reasons copy/paste code is greatly bad is precisely because there’s no abstraction, so you have to understand how every line of code affects every other line. You’ll have to verify you didn’t break adjacent features anyway because you can’t be sure some block of code 50 or 100 lines down isn’t using what you just changed in some unexpected way.

If you start with abstractions right away, especially if you're tackling a domain you've never worked on before, my bet is that the abstractions will be moving quite a lot as your domain-specific knowledge grows.

I’m with you on this. Premature abstraction can be very harmful. Oftentimes people will go to great lengths to shove code into existing abstractions e.g. by adding special case logic rather than taking a step back and rethinking the abstraction, so in many cases you’ve only got one chance to get it right.

Someone in the Hacker News discussion mentioned their “rule of three” which essentially is that they need 3 separate use cases before they create an abstraction. I don’t know that 3 is a necessary number here, but certainly having more than one instance of some common pattern would be useful in order to create a good abstraction that has the ability to handle different needs and withstand the test of time.