3 ms·

I see this all the time in well-intentioned "agile" projects. They fail to fully understand the domain and then micro optimisations like this lead to features b

I see this all the time in well-intentioned "agile" projects. They fail to fully understand the domain and then micro optimisations like this lead to features breaking in interesting and unexpected ways.

smitty1e 6y ago
I get a kick out of the OO languages that factor everything to such a fine granularity that there seems to be one line of executable code per class. The exception traces go on for a couple of screens, so I guess the coders feel like their CompSci degrees are justified.
- TeMPOraL 6y ago
  On a related note, I've seen people taking this too far in functional/procedural code. Not every concept needs its explicit name, not every function needs to be 5 lines of code or less. All that jumping around between function definitions is a serious impediment to readability. (EDIT: this is mentioned in the article as "localization complexity")
  - sitkack 6y ago
    > Not every concept needs its explicit name There is a special subgenre of functional programming, where the style is to explicitly not have names https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Tacit_programming (also known as point-free)
  - dsego 6y ago
    I've been thinking about it lately. Esp. since I've taken another look at the refactoring chapters of Clean Code, but instead of being enlightened I felt disgusted. Like, for-loops are ok, if-statements are ok, those are the basic constructs of code, you can see the shapes visually and it's easy to follow the code path. This is what you find in low level C/C++ code, lots of switches, loops and conditionals. Those programmers just get used to the verbosity and look at shapes instead of reading line by line. Maybe it's easier for subtle mistakes to pass unnoticed, but refactoring out everything into layers of abstraction brings jumping around and context switching between these different pieces and trying to make a mental picture of how it all fits together.
- hinkley 6y ago
  There are ways to flatten those trees and leave the code a bit more readable. Bertrand Meyer hit on it 30 years ago: if (weShouldDoThis()) { return doIt(); } Structurally, this seems very similar to having twenty methods with one conditional block and a delegation to some other method. But the stack trace is half as high, and the testing surface area is greatly improved, because the code in the 'if' clause is pure, or close to it, while the 'doIt()' method might alter shared state. There's a big difference from a robustness standpoint between having half of your functions pure, and half of each function pure.
- Applejinx 6y ago
  That stuff drives me insane. Can't cope with it at all. I'm working in audio DSP as a rule, so I already have to maintain state of 'what the audio is doing related to this set of sample data', and often some things about how controls must move and feed information into the program to relate to a desired change in the audio which itself can be somewhat indirect. Maybe I am just stupid, but when I have to track DRY code I just blow a gasket immediately and can't parse it at all. I've wondered whether some of that stuff is about taking trivial problems and making them hard to follow for the uninitiated, to protect employment. WHY not repeat yourself, when the problem is repeated tasks? Or more relevantly, why not write a complicated and long sentence, rather than mangle the sentence into a series of more abbreviated footnotes? DRY reads to me like that chain of footnotes. You lose the plot. Well, I do :)

smitty1e 6y ago

I get a kick out of the OO languages that factor everything to such a fine granularity that there seems to be one line of executable code per class. The exception traces go on for a couple of screens, so I guess the coders feel like their CompSci degrees are justified.

TeMPOraL 6y ago
On a related note, I've seen people taking this too far in functional/procedural code. Not every concept needs its explicit name, not every function needs to be 5 lines of code or less. All that jumping around between function definitions is a serious impediment to readability. (EDIT: this is mentioned in the article as "localization complexity")
- sitkack 6y ago
  > Not every concept needs its explicit name There is a special subgenre of functional programming, where the style is to explicitly not have names https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Tacit_programming (also known as point-free)
- dsego 6y ago
  I've been thinking about it lately. Esp. since I've taken another look at the refactoring chapters of Clean Code, but instead of being enlightened I felt disgusted. Like, for-loops are ok, if-statements are ok, those are the basic constructs of code, you can see the shapes visually and it's easy to follow the code path. This is what you find in low level C/C++ code, lots of switches, loops and conditionals. Those programmers just get used to the verbosity and look at shapes instead of reading line by line. Maybe it's easier for subtle mistakes to pass unnoticed, but refactoring out everything into layers of abstraction brings jumping around and context switching between these different pieces and trying to make a mental picture of how it all fits together.
hinkley 6y ago
There are ways to flatten those trees and leave the code a bit more readable. Bertrand Meyer hit on it 30 years ago: if (weShouldDoThis()) { return doIt(); } Structurally, this seems very similar to having twenty methods with one conditional block and a delegation to some other method. But the stack trace is half as high, and the testing surface area is greatly improved, because the code in the 'if' clause is pure, or close to it, while the 'doIt()' method might alter shared state. There's a big difference from a robustness standpoint between having half of your functions pure, and half of each function pure.
Applejinx 6y ago
That stuff drives me insane. Can't cope with it at all. I'm working in audio DSP as a rule, so I already have to maintain state of 'what the audio is doing related to this set of sample data', and often some things about how controls must move and feed information into the program to relate to a desired change in the audio which itself can be somewhat indirect. Maybe I am just stupid, but when I have to track DRY code I just blow a gasket immediately and can't parse it at all. I've wondered whether some of that stuff is about taking trivial problems and making them hard to follow for the uninitiated, to protect employment. WHY not repeat yourself, when the problem is repeated tasks? Or more relevantly, why not write a complicated and long sentence, rather than mangle the sentence into a series of more abbreviated footnotes? DRY reads to me like that chain of footnotes. You lose the plot. Well, I do :)