3 ms·

The code is not large enough to need maintenance at a fine-grained level. There is a secondary rule to the DRY "rule of three": If I can blow it away and rewri

The code is not large enough to need maintenance at a fine-grained level. There is a secondary rule to the DRY "rule of three": If I can blow it away and rewrite it so easily, there is nothing to reuse or refactor in it. The feature is done, and we are into code golf and speculation, neither of which are productive uses of time. In my experience the success rate of speculative refactors like the one author made has perhaps a 50/50 chance, so no better than the initial strategy. It's the requirements themselves and the application of techniques to avoid various classes of errors that give code direction and structure - not the aesthetics at a moment in time(which is what author took issue with). If you spot multiple approaches on the first try, you can add a comment with a date outlining alternatives so that the conversation may be resumed later when the new requirements come in. But at all times you're always at the mercy of "discipline", and there's no preemptive measure that avoids that.

Rapzid 7y ago
The author also didn't sound like a particularly senior engineer at the time for many reasons. So the original code author and the "boss" may have been taking into consideration timelines and future work/requirements coming down the pipe. A very valid reason could have been as simple as "We are re-visiting this in a couple sprints after feedback and will have a better idea of how it needs to change. The extra day spent on this wasn't worth pushing getting it into peoples hands, and we don't know if it would be a waste." The author would have known this if he started a conversation about it.
- cc81 7y ago
  I heard something like: "The second system you design will be the most over engineered piece of shit ever" I don't know who said it but it has been very true for me and my close friends who work in software development. I remember first starting software development and I started to read up on "how to do it right" in the Java/C# world back when XML was everywhere. I had first started to expand my skills after university by building my own blog (who didn't at that time?) but thought I should rebuild it according to "best practices". Hoooooly shit that was a poorly architected and designed piece of software. The example in the blog was of course not as poor of an example as my creation but I feel that many end up in this trap after they have some experience that they need to do everything "right" and they don't have the experience to evaluate if it is worth it. However I also think a good workplace have a healthy mix because those youngsters will also push the old guard to learn new things and introduce new technology. Just need a balance between using 0.1-alpha libraries and things that were released 10 years ago.
leoc 7y ago
> There is a secondary rule to the DRY "rule of three": If I can blow it away and rewrite it so easily, there is nothing to reuse or refactor in it. This rule seems not to be correct though. For example it would mean that one of the most common and widely accepted (as far as I know, and admittedly I know nothing) changes—replacing an explicit for or while loop with some kind of iterator construct, for example a foreach or even a call to a map function—was a bad idea. By and large most individual for loops are pretty easy to understand and rewrite if you look at them. The first problem is that naturally one hardly ever has to read just a single for loop, and that the impact of small insults to abstraction and readability really adds up when repeated tens to thousands of times in a codebase. Second: that a piece of code is easy to read, blow away and rewite is very far from a guarantee of no bugs in either the old or the new version, and AFAIK the history of the vanilla for loop is a classic example of that. Again the impact of this depends on the fact that the for loop can be repeated many times in a codebase. OTOH the example code in TFA was not repeated with (or without) small variations many times in the program. (I'm not talking about how often it was called or about repetition inside the example code here, ofc.) So your test probably does correctly show that changing or not changing this piece of code on its own is only a small-stakes decision, unlike having say 500 vanilla for loops in the program. But if you consistently let individual bodgy code segments pass then surely you're liable to end up with a large and diverse body of them in the codebase, and that's in some ways even worse than 500 for loops, which can at least all be found with a simple search.

Rapzid 7y ago

The author also didn't sound like a particularly senior engineer at the time for many reasons. So the original code author and the "boss" may have been taking into consideration timelines and future work/requirements coming down the pipe. A very valid reason could have been as simple as "We are re-visiting this in a couple sprints after feedback and will have a better idea of how it needs to change. The extra day spent on this wasn't worth pushing getting it into peoples hands, and we don't know if it would be a waste." The author would have known this if he started a conversation about it.

cc81 7y ago
I heard something like: "The second system you design will be the most over engineered piece of shit ever" I don't know who said it but it has been very true for me and my close friends who work in software development. I remember first starting software development and I started to read up on "how to do it right" in the Java/C# world back when XML was everywhere. I had first started to expand my skills after university by building my own blog (who didn't at that time?) but thought I should rebuild it according to "best practices". Hoooooly shit that was a poorly architected and designed piece of software. The example in the blog was of course not as poor of an example as my creation but I feel that many end up in this trap after they have some experience that they need to do everything "right" and they don't have the experience to evaluate if it is worth it. However I also think a good workplace have a healthy mix because those youngsters will also push the old guard to learn new things and introduce new technology. Just need a balance between using 0.1-alpha libraries and things that were released 10 years ago.

leoc 7y ago

> There is a secondary rule to the DRY "rule of three": If I can blow it away and rewrite it so easily, there is nothing to reuse or refactor in it. This rule seems not to be correct though. For example it would mean that one of the most common and widely accepted (as far as I know, and admittedly I know nothing) changes—replacing an explicit for or while loop with some kind of iterator construct, for example a foreach or even a call to a map function—was a bad idea. By and large most individual for loops are pretty easy to understand and rewrite if you look at them. The first problem is that naturally one hardly ever has to read just a single for loop, and that the impact of small insults to abstraction and readability really adds up when repeated tens to thousands of times in a codebase. Second: that a piece of code is easy to read, blow away and rewite is very far from a guarantee of no bugs in either the old or the new version, and AFAIK the history of the vanilla for loop is a classic example of that. Again the impact of this depends on the fact that the for loop can be repeated many times in a codebase. OTOH the example code in TFA was not repeated with (or without) small variations many times in the program. (I'm not talking about how often it was called or about repetition inside the example code here, ofc.) So your test probably does correctly show that changing or not changing this piece of code on its own is only a small-stakes decision, unlike having say 500 vanilla for loops in the program. But if you consistently let individual bodgy code segments pass then surely you're liable to end up with a large and diverse body of them in the codebase, and that's in some ways even worse than 500 for loops, which can at least all be found with a simple search.