"A common mistake I see is people thinking that “Less Code” === “Better” for some odd reason."
I couldn't agree more.
I remember we had this debate in my team (and with others in my company) and I raised this exact point with a simple addition that less code does not necessarily equate to better or more maintainable or less complex code.
Often, devs (even seniors) think that the principle of DRYness naively means less code. So they go about trying to fit an Animal and Car objects into one base object that does everything thus violating all other principles. Especially that which is arguably the most important for maintainable, testable code: the Single Responsibility Principle!
We had an interesting situation at my company where one integration layer service code was noticeably duplicated on each new integration; because the said integrations are rather similar only differing in a few bits and pieces. And as they kept growing, so did this duplication and the nightmare of maintaining such code. Naturally, a refactor followed. I supposed the team was so weary of code duplication (and by extension too much code) that they fell into the pitfall of thinking DRY code naively means less code. All other principles of design were seemingly put aside. So they refactored that codebase into a nice "mini-framework" (incidentally that was the name given to it) of a few base classes that implement "common" behaviour while apply meta-programming (as it's a Python codebase) to create and validate concrete sub-classes. I cringe every time!
As you can imagine, the result was DRY (loosely used to mean less) code whose complexity was significantly increased to the point that when the company decided to scale its engineering team and hired a bunch of us (thrice the original team that did the refactoring), we had a very hard time making sense of that codebase. Sure the base classes are simple to use as all you have to do is inherit and add one or two lines that implement abstract methods, but they are themselves complex to understand and maintain.
Nothing sums it up better than this excerpt from the blog post I want off Mr. Golang’s Wild Ride:
Simple is a lie
Over and over, every piece of documentation for the Go language markets it as “simple”.
This is a lie.
Or rather, it’s a half-truth that conveniently covers up the fact that, when you make something simple, you move complexity elsewhere.
