5 ms·

I'm always curious about whether or not people are lumping in lower-level "coding best-practice" concepts like DRY in with this idea of "complexity." It's fine

I'm always curious about whether or not people are lumping in lower-level "coding best-practice" concepts like DRY in with this idea of "complexity." It's fine to complain about people who "over-engineer" things, but I've also come across cases where someone uses "I'm Agile" as an excuse to completely throw out any and all coding structure or best practices. And every time I try to say that maybe we should spend 3 seconds to remove the comments that are in Chinese and maybe adapt the code to our naming conventions after literally copy&pasting it in from StackOverflow, I get pointed to arguments like this post for why none of that stuff matters.

deong 10y ago
No one is against coding structure, or even "best practices", if you interpret it as meaning the thing someone fluent in English but with no background in software development would understand it to mean. The problem is that "best practices" in our industry has become a specific term meaning "overly complicated by a factor of about seven, but with enough meaningless jargon invented to describe it that no one feels comfortable saying the emperor is in fact naked".
- Benjammer 10y ago
  I totally agree with you, I just think that the ideas being discussed in this thread have a ton of nuance and they can be dangerous to introduce to a junior developer who doesn't quite realize the difference between the idea of "complexity" we're talking about here and the fact that he shouldn't be copy-pasting boilerplate code all over the app and copy-pasting directly from StackOverflow without any editing or integration of the code.
- lgunsch 10y ago
  I would agree with that definition has become the new interpretation of "best practices". However, in my 5 year career I have seen the majority of solutions under-engineered. That is much more of an issue these days than over-engineering.
  - Benjammer 10y ago
    >majority of solutions under-engineered. That is much more of an issue these days than over-engineering. Couldn't agree more.
soundwave106 10y ago
The problem isn't "best practice" per se, it's "best practice" in practice. :) I can see good use cases for OOP, for instance, but OOP's definitely a leading contender for the "over-engineering" trap. I've certainly seen my share of "OOP / pattern spaghetti" to the point where just coding a simple select call involves writing several classes in random locations in the project. Like goto spaghetti, the result is way harder to debug and maintain. I personally think lower level advice like DRY is much more important overall than patterns (in many OOP projects, it seems, I feel like they violate the KISS principle for no real benefit). Even naming conventions can fall in this trap. Consistent naming convention is absolutely a great idea. And then you run into the database that have several naming conventions, all inconsistently applied depending on the state of the project at the time. I've found inconsistent naming conventions not much more useful than no naming convention at all.
- Benjammer 10y ago
  >I've found inconsistent naming conventions not much more useful than no naming convention at all. Try working with someone who's idea of expanding the app is literally taking a controller class for another page that does something vaguely related to the new feature, copy-pasting it into a new file, changing the class name (like put an "N" at the end of it like "SearchResultsView"-->"SearchResultsViewN"), and then changing some of the internal business logic without changing the names of any methods or variables. What you're left with is something that is much, much worse than no naming conventions at all. It's actually naming conventions that actively mislead you as to their scope and function. Like a "clickedEditButton()" method that is actually wired up to a "back" button on the page and takes you back to the previous screen.

deong 10y ago

No one is against coding structure, or even "best practices", if you interpret it as meaning the thing someone fluent in English but with no background in software development would understand it to mean. The problem is that "best practices" in our industry has become a specific term meaning "overly complicated by a factor of about seven, but with enough meaningless jargon invented to describe it that no one feels comfortable saying the emperor is in fact naked".

Benjammer 10y ago
I totally agree with you, I just think that the ideas being discussed in this thread have a ton of nuance and they can be dangerous to introduce to a junior developer who doesn't quite realize the difference between the idea of "complexity" we're talking about here and the fact that he shouldn't be copy-pasting boilerplate code all over the app and copy-pasting directly from StackOverflow without any editing or integration of the code.
lgunsch 10y ago
I would agree with that definition has become the new interpretation of "best practices". However, in my 5 year career I have seen the majority of solutions under-engineered. That is much more of an issue these days than over-engineering.
- Benjammer 10y ago
  >majority of solutions under-engineered. That is much more of an issue these days than over-engineering. Couldn't agree more.

soundwave106 10y ago

The problem isn't "best practice" per se, it's "best practice" in practice. :) I can see good use cases for OOP, for instance, but OOP's definitely a leading contender for the "over-engineering" trap. I've certainly seen my share of "OOP / pattern spaghetti" to the point where just coding a simple select call involves writing several classes in random locations in the project. Like goto spaghetti, the result is way harder to debug and maintain. I personally think lower level advice like DRY is much more important overall than patterns (in many OOP projects, it seems, I feel like they violate the KISS principle for no real benefit). Even naming conventions can fall in this trap. Consistent naming convention is absolutely a great idea. And then you run into the database that have several naming conventions, all inconsistently applied depending on the state of the project at the time. I've found inconsistent naming conventions not much more useful than no naming convention at all.

Benjammer 10y ago
>I've found inconsistent naming conventions not much more useful than no naming convention at all. Try working with someone who's idea of expanding the app is literally taking a controller class for another page that does something vaguely related to the new feature, copy-pasting it into a new file, changing the class name (like put an "N" at the end of it like "SearchResultsView"-->"SearchResultsViewN"), and then changing some of the internal business logic without changing the names of any methods or variables. What you're left with is something that is much, much worse than no naming conventions at all. It's actually naming conventions that actively mislead you as to their scope and function. Like a "clickedEditButton()" method that is actually wired up to a "back" button on the page and takes you back to the previous screen.