4 ms·

I can't believe no one's saying this. If you're asking, then YES, DO IT. First of all, I'll assume you're not an idiot. If you're an idiot, and your task requ

by MBlume 14y ago

I can't believe no one's saying this. If you're asking, then YES, DO IT. First of all, I'll assume you're not an idiot. If you're an idiot, and your task requires you to interact with this code, you're fucked no matter what. So, assuming you're not an idiot, and you've asked the question, means you're already pretty damn confident this code's not on a critical path. And what does that mean? Means some asshole was showing off how clever ey was by prematurely optimizing, and it's already come back to bite you in the form of difficult maintenance. So take a blowtorch to it already.

jandrewrogers 14y ago
On the other hand, the reverse is true as well. Most software engineers, smart or not, do not have the skill or experience to even analyze the intent of highly-optimized implementations. The complexity is obvious but the interactions being manipulated are not unless software system optimization is a domain of expertise. It would be like asking me to analyze GUI design. I have seen many examples of smart engineers being "damn confident" that code was over-engineered and possibly even suboptimal only to make the code simpler, sometimes even faster, and broken. I design high-performance software systems and am the optimization guy. There have been many cases where a smart engineer decides that I am actually "some asshole showing off how clever ey was" and then "fixes" my work. Which then has to be redone when the purpose of the original implementation rematerializes. The engineers in these cases are not idiots, they simply don't understand the nature of the optimization or why it is happening in a particular place. There are many cases of premature optimization but that is not always the case just because it looks like it. If there are people around that actually understand optimization then at least ask one of them about the code in question, particularly if they wrote it.
- quanticle 14y ago
  Exactly. It's too easy to break Zawinsky's first commandment (Thou shalt not break working code) with changes like this. Sure, if the code is getting in the way of a change, then go ahead and change it. But I don't think that's what the questioner is asking. It seems like he or she has noticed this "ugly" code and wants to change it out of a misplaced sense of conscientiousness. EDIT: I just remembered that something like this happened to me when I was an intern at my first position doing "real" software development. I'd noticed a particular piece of gnarly code and asked my team lead for permission to refactor. He, in turn, told me that for a rarely used code path like the one I was proposing to refactor, the costs of QA and deployment would greatly outweigh any savings my changes would generate for the company. His concluding words were, "Sometimes it's easier to let sleeping dogs lie," and I think that's something that applies to this situation as well.
  - MBlume 14y ago
    First paragraph: > Sometimes you run into a situation where you have to extend/improve some existing code. You see that the old code is very lean, but it's also difficult to extend, and takes time to read. Last paragraph: > Is it a good idea to change such code if you have to touch a small piece of it either way?
- brazzy 14y ago
  If the intent of those code optimizations are so damn hard to understand and there are such subtle bugs they avoid in very specific ways, why isn't there a comment to explain the intent and a unit test to ensure it's not broken? Sounds like it's not those other engineer's fault that this kind of thing keeps happening to your code...
  - jandrewrogers 14y ago
    The code is perfectly clear and well-documented. In most of the cases, the problem is that most software engineers have no clue how the hardware (or operating system) their software runs on actually works. Consequently, they are oblivious to potential side-effects of innocuous-looking code changes that the original author accounted for. There is always documentation explaining the optimization and intent but many engineers do not have the background knowledge to understand how that is achieved. The code optimizations are easy to understand if you know how to optimize code. The problem is that most software engineers do not, nor do they know what optimizations look like even when the code itself is easy to understand. So the best we can do is annotate that code with the fact that some important optimizations were made there and to understand the nature of those optimizations. Also, it is difficult to impossible to unit test many optimizations. Many of them are about minimizing interactions between concurrent but unrelated processes or minimizing the latency of some code path. The functionality can be correct and fast in unit tests and the run-time behavior in operational environments still be pathological because of potential interactions that are nearly impossible to replicate in the unit test environment. You can run simulated workloads but those are much more expensive to do and for any kind of non-trivial system the coverage will be poor relative to the kinds of problems you may have.

by MBlume 14y ago

jandrewrogers 14y ago

On the other hand, the reverse is true as well. Most software engineers, smart or not, do not have the skill or experience to even analyze the intent of highly-optimized implementations. The complexity is obvious but the interactions being manipulated are not unless software system optimization is a domain of expertise. It would be like asking me to analyze GUI design. I have seen many examples of smart engineers being "damn confident" that code was over-engineered and possibly even suboptimal only to make the code simpler, sometimes even faster, and broken. I design high-performance software systems and am the optimization guy. There have been many cases where a smart engineer decides that I am actually "some asshole showing off how clever ey was" and then "fixes" my work. Which then has to be redone when the purpose of the original implementation rematerializes. The engineers in these cases are not idiots, they simply don't understand the nature of the optimization or why it is happening in a particular place. There are many cases of premature optimization but that is not always the case just because it looks like it. If there are people around that actually understand optimization then at least ask one of them about the code in question, particularly if they wrote it.

quanticle 14y ago
Exactly. It's too easy to break Zawinsky's first commandment (Thou shalt not break working code) with changes like this. Sure, if the code is getting in the way of a change, then go ahead and change it. But I don't think that's what the questioner is asking. It seems like he or she has noticed this "ugly" code and wants to change it out of a misplaced sense of conscientiousness. EDIT: I just remembered that something like this happened to me when I was an intern at my first position doing "real" software development. I'd noticed a particular piece of gnarly code and asked my team lead for permission to refactor. He, in turn, told me that for a rarely used code path like the one I was proposing to refactor, the costs of QA and deployment would greatly outweigh any savings my changes would generate for the company. His concluding words were, "Sometimes it's easier to let sleeping dogs lie," and I think that's something that applies to this situation as well.
- MBlume 14y ago
  First paragraph: > Sometimes you run into a situation where you have to extend/improve some existing code. You see that the old code is very lean, but it's also difficult to extend, and takes time to read. Last paragraph: > Is it a good idea to change such code if you have to touch a small piece of it either way?
brazzy 14y ago
If the intent of those code optimizations are so damn hard to understand and there are such subtle bugs they avoid in very specific ways, why isn't there a comment to explain the intent and a unit test to ensure it's not broken? Sounds like it's not those other engineer's fault that this kind of thing keeps happening to your code...
- jandrewrogers 14y ago
  The code is perfectly clear and well-documented. In most of the cases, the problem is that most software engineers have no clue how the hardware (or operating system) their software runs on actually works. Consequently, they are oblivious to potential side-effects of innocuous-looking code changes that the original author accounted for. There is always documentation explaining the optimization and intent but many engineers do not have the background knowledge to understand how that is achieved. The code optimizations are easy to understand if you know how to optimize code. The problem is that most software engineers do not, nor do they know what optimizations look like even when the code itself is easy to understand. So the best we can do is annotate that code with the fact that some important optimizations were made there and to understand the nature of those optimizations. Also, it is difficult to impossible to unit test many optimizations. Many of them are about minimizing interactions between concurrent but unrelated processes or minimizing the latency of some code path. The functionality can be correct and fast in unit tests and the run-time behavior in operational environments still be pathological because of potential interactions that are nearly impossible to replicate in the unit test environment. You can run simulated workloads but those are much more expensive to do and for any kind of non-trivial system the coverage will be poor relative to the kinds of problems you may have.