3 ms·
Sorry for ranting. I've been reading articles like this one for many years now, and I've certainly learnt a lot through them. Lately though, it feels as though
by whack 9y ago
Sorry for ranting. I've been reading articles like this one for many years now, and I've certainly learnt a lot through them. Lately though, it feels as though we as a profession are just going around in circles, not making any real progress.
More and more, these articles remind me of schoolyard wisdom, the kind people love to throw around because they sound wise. "Winners never quit." "Quitters never win". "Quit while you're ahead". Taken individually, they all sound perfectly reasonable and wise. Put them together, and clearly there's something wrong.
This article strikes me in the same vein. "YAGNI. Keep your code as simple as possible. Focus on your code as it is right now, and not what's going to happen in the future". "The only constant is change. Business requirements are always in flux. The mark of good code is the ability to change its behavior without overhauling everything". Taken individually, they both sound perfectly reasonable, but put them together, and something is clearly wrong.
Maybe it's time we accepted that there is no one right way. No one all-important metric or rule that trumps everything else. That simplicity is important, that conciseness is important, that DRY is important, that being able to adapt to future changes is important. That good code finds a balance between all of the above, without sacrificing one on the altar of another. That instead of writing articles trying to elevate one over another by attacking strawmen, we should instead present realistic code examples, thorough which we can have a grounded discussion on how best to find the balance between all the different qualities that comprise good code.
It's not going to be as easy or fun as simply declaring "X considered harmful", but it's going to help elevate the quality of our discussion, and help our profession progress to the next level.
- Veedrac 9y ago> Taken individually, they both sound perfectly reasonable, but put them together, and something is clearly wrong. Which makes sense; the former is a rebuttal of the latter. The C or Go philosophy is fundamentally at odds with the C++ or Haskell philosophy.
- makapuf 9y agoId say that this article is trying to be too general and give advice for a too broad case. It would be better to focus on real world cases, solve them and try to find some slightly generalised advice </meta>