3 ms·

(6) Happens even when you know better. (10) Good programmers don't repeat themselves, true, and to continually improve as a programmer it is important to patie

by Goladus 19y ago

(6) Happens even when you know better. (10) Good programmers don't repeat themselves, true, and to continually improve as a programmer it is important to patiently do everything correctly the first time. However, obsessing over a few bits of code duplication is often a complete waste of time.

edw519 19y ago
"...obsessing over a few bits of code duplication is often a complete waste of time." For you, maybe. But what about the guy who applies enhancements 3 years later and has trouble getting through testing because the exact same code was somewhere else and difficult to find because of the 67 mods since then. Minutes "obsessing" today usually saves hours testing tomorrow.
- Goladus 19y ago
  "Minutes "obsessing" today usually saves hours testing tomorrow." True, but the app has to make it to tomorrow for testing to matter at all. It's better to be in the championship trying to figure out how to manage a tired team, than it is to conserve energy during the semifinals and wind up sitting in the bleachers.
  - edw519 19y ago
    Where'd you ever get the idea that there is any trade-off between "quick" and "right"? Doing things according to effective established principles saves a little time today and a lot of time tomorrow. Quick and dirty usually ends up being neither.
    - Goladus 19y ago
      Where'd you ever get the idea that there is any trade-off between "quick" and "right"? I don't have that idea. There is sometimes, though, a tradeoff between current needs and future needs; and that tradeoff can not always be predicted. When that happens, it's logical to give current demands priority. I can't for example, predict whether a future maintainer of my code would prefer code written with multiple returns, or code that sets temporary values, or code that uses a set of nested ifs, or code that assigns function pointers to a matrix and calls code based on the indices. Each technique has potential drawbackss in terms of future maintainability, likelihood of errors, and speed of immediate implementation. Trying to guess what a future coder (other than myself) will think is just not important in that case. Effective Principles can only be Established based on a given development environment, and it's the responsibility of those in charge of the environment to make sure the established principles are effective and followed by the developers.
    - timr 19y ago
      If it were really true that "effective established principles" save time on both the front and the back end, then everyone would be doing them. The fact is, there's almost always a trade-off between "quick" and "right". That's why so many people choose the former, to the detriment of the latter.
- nostrademons 19y ago
  I usually follow the childhood adage "First time it's funny, second time it's silly, third time's a spanking." Probably better summed up as http://www.c2.com/cgi/wiki?ThreeStrikesAndYouRefactor http://www.c2.com/cgi/wiki?ThreeStrikesAndYouRefactor. Problem is, after 2 repetitions you often don't know what the real abstraction behind the duplicated code is, and so you end up with convoluted objects or closures to swap out parts of behavior, while there's a more natural abstraction just around the corner. If you mercilessly refactor after only the first duplication, you might not see it after the second, because the original code has been abstracted enough that it doesn't look like the third repetition. This also squares with a lot of IBM's experience in The Mythical Man Month, i.e. code needs at least three clients to really be reusable.
DanielBMarkham 19y ago
"obsessing over a few bits of code duplication..." Applying good coupling and cohesion principles is not obsessing. It's as much legitimate programming as writing an equality test.
- Goladus 19y ago
  It is obsessing if it detracts from the end product. I'm not saying DRY isn't good practice or that chunks of code duplication are just fine and dandy. However, bits of code duplication are hardly a viable litmus test for judging quality of a programmer. When an actor screws up a line in a performance, he can't afford to stop and correct it. In fact, if he stops to correct a meaningless line he'll cause far more damage than if he'd just kept going. Programming is not always so time-and-performance-sensitive, but it's not time-insensitive either. Perfect programmers may manage to avoid duplicating code on the first try. But unless we have dozens of Mozarts posting here I'd guess that no one qualifies. That means we make mistakes, and the question of whether correcting those mistakes is good practice or obsession depends on the circumstances.
  - DanielBMarkham 19y ago
    I'm trying to find some point of agreement with you. I think from your comment, we can agree that there are two scenarios to consider: when the programmer is in control of the product and when the schedule is in control of the product. "Programming is not always so time-and-performance-sensitive, but it's not time-insensitive either." Here's the deal: when you stop your design process and kick the compiler up and start coding, you haven't stopped your design work at all, you've simply switched from top-down to bottom-up design. Every line of code you write is a validation/denial of the assumptions and planning you're supposed to do before you start. If you're not refactoring aggressively as you go along, you're not taking the chance to see where your code is supposed to be going: you're simply trying as hard as you can to get to point B from point A. It's like driving a car from one side of the field to the other by letting go of the steering wheel and hoping it gets there okay. Most of the time you make it to the other side just fine, but you have zero control over where on the other side you're going to end up. To me, that's hacking, and I mean in a bad way. I've been known to hack like a freaking electric weed-eater, trust me! But that's when something else is out of whack on the project. It's a sign that there are serious problems. When you're doing it right, your code is constantly evolving as you refactor to the point where changes become less and less of an issue. So good programming means you spend all the time necessary to refactor with the knowledge that you'll going to make it back in spades later on. It's like when playing rummy, and you decide to pick up a huge stack of cards. At first, it seems like a crazy move, but if you know how to play the game, you realize that the only way to win is to constantly redefine the problem domain of what you have in your hand. Hacking doesn't get you that -- it just gets you to point B no matter what. It may not be the sign of poor programmer, but it's definitely a red light that something is out of whack somewhere. My opinion only. Your mileage may vary. Do not attempt to drive heavy machinery after reading my comments. Consult a physician before beginning a regimen of refactoring. Etc.

by Goladus 19y ago

edw519 19y ago

"...obsessing over a few bits of code duplication is often a complete waste of time." For you, maybe. But what about the guy who applies enhancements 3 years later and has trouble getting through testing because the exact same code was somewhere else and difficult to find because of the 67 mods since then. Minutes "obsessing" today usually saves hours testing tomorrow.

Goladus 19y ago
"Minutes "obsessing" today usually saves hours testing tomorrow." True, but the app has to make it to tomorrow for testing to matter at all. It's better to be in the championship trying to figure out how to manage a tired team, than it is to conserve energy during the semifinals and wind up sitting in the bleachers.
- edw519 19y ago
  Where'd you ever get the idea that there is any trade-off between "quick" and "right"? Doing things according to effective established principles saves a little time today and a lot of time tomorrow. Quick and dirty usually ends up being neither.
  - Goladus 19y ago
    Where'd you ever get the idea that there is any trade-off between "quick" and "right"? I don't have that idea. There is sometimes, though, a tradeoff between current needs and future needs; and that tradeoff can not always be predicted. When that happens, it's logical to give current demands priority. I can't for example, predict whether a future maintainer of my code would prefer code written with multiple returns, or code that sets temporary values, or code that uses a set of nested ifs, or code that assigns function pointers to a matrix and calls code based on the indices. Each technique has potential drawbackss in terms of future maintainability, likelihood of errors, and speed of immediate implementation. Trying to guess what a future coder (other than myself) will think is just not important in that case. Effective Principles can only be Established based on a given development environment, and it's the responsibility of those in charge of the environment to make sure the established principles are effective and followed by the developers.
  - timr 19y ago
    If it were really true that "effective established principles" save time on both the front and the back end, then everyone would be doing them. The fact is, there's almost always a trade-off between "quick" and "right". That's why so many people choose the former, to the detriment of the latter.
nostrademons 19y ago
I usually follow the childhood adage "First time it's funny, second time it's silly, third time's a spanking." Probably better summed up as http://www.c2.com/cgi/wiki?ThreeStrikesAndYouRefactor http://www.c2.com/cgi/wiki?ThreeStrikesAndYouRefactor. Problem is, after 2 repetitions you often don't know what the real abstraction behind the duplicated code is, and so you end up with convoluted objects or closures to swap out parts of behavior, while there's a more natural abstraction just around the corner. If you mercilessly refactor after only the first duplication, you might not see it after the second, because the original code has been abstracted enough that it doesn't look like the third repetition. This also squares with a lot of IBM's experience in The Mythical Man Month, i.e. code needs at least three clients to really be reusable.

DanielBMarkham 19y ago

"obsessing over a few bits of code duplication..." Applying good coupling and cohesion principles is not obsessing. It's as much legitimate programming as writing an equality test.

Goladus 19y ago
It is obsessing if it detracts from the end product. I'm not saying DRY isn't good practice or that chunks of code duplication are just fine and dandy. However, bits of code duplication are hardly a viable litmus test for judging quality of a programmer. When an actor screws up a line in a performance, he can't afford to stop and correct it. In fact, if he stops to correct a meaningless line he'll cause far more damage than if he'd just kept going. Programming is not always so time-and-performance-sensitive, but it's not time-insensitive either. Perfect programmers may manage to avoid duplicating code on the first try. But unless we have dozens of Mozarts posting here I'd guess that no one qualifies. That means we make mistakes, and the question of whether correcting those mistakes is good practice or obsession depends on the circumstances.
- DanielBMarkham 19y ago
  I'm trying to find some point of agreement with you. I think from your comment, we can agree that there are two scenarios to consider: when the programmer is in control of the product and when the schedule is in control of the product. "Programming is not always so time-and-performance-sensitive, but it's not time-insensitive either." Here's the deal: when you stop your design process and kick the compiler up and start coding, you haven't stopped your design work at all, you've simply switched from top-down to bottom-up design. Every line of code you write is a validation/denial of the assumptions and planning you're supposed to do before you start. If you're not refactoring aggressively as you go along, you're not taking the chance to see where your code is supposed to be going: you're simply trying as hard as you can to get to point B from point A. It's like driving a car from one side of the field to the other by letting go of the steering wheel and hoping it gets there okay. Most of the time you make it to the other side just fine, but you have zero control over where on the other side you're going to end up. To me, that's hacking, and I mean in a bad way. I've been known to hack like a freaking electric weed-eater, trust me! But that's when something else is out of whack on the project. It's a sign that there are serious problems. When you're doing it right, your code is constantly evolving as you refactor to the point where changes become less and less of an issue. So good programming means you spend all the time necessary to refactor with the knowledge that you'll going to make it back in spades later on. It's like when playing rummy, and you decide to pick up a huge stack of cards. At first, it seems like a crazy move, but if you know how to play the game, you realize that the only way to win is to constantly redefine the problem domain of what you have in your hand. Hacking doesn't get you that -- it just gets you to point B no matter what. It may not be the sign of poor programmer, but it's definitely a red light that something is out of whack somewhere. My opinion only. Your mileage may vary. Do not attempt to drive heavy machinery after reading my comments. Consult a physician before beginning a regimen of refactoring. Etc.