4 ms·

I find it very very true, however. The time necessary to understand why the fence was put up, it is usually greater than the time necessary to push down the fe

by siscia 6y ago

I find it very very true, however. The time necessary to understand why the fence was put up, it is usually greater than the time necessary to push down the fence, test the system, and put back up the fence if necessary.

ColinWright 6y ago
Except that you don't always know all the ways the system needs to be tested. I've come across code that was broken, seriously broken, multiple thousands of pounds broken, because someone replaced apparently pointless code with something simpler, tested every case they thought of, and deployed it. Are your tests really complete? Have you tested everything? Perhaps we simply work in different fields, and there are things that matter to me that you would shrug off and not care about.
- siscia 6y ago
  Indeed it is a fine balance. However, what I am trying to convey is that the burder of explaining and testing the code, and why the code is needed, should be on who put it out first. If we are not brave and decisive when we decide to cut code, the complexity of the codebase will just explode in no time. It is already extremely difficult to simplify and remove code, if the person doing this job is also the one that need to figure out, from scratch without documentation, why the code was put there in the first place, the simplification is never going to happen.
  - ColinWright 6y ago
    > ... the burden of explaining and testing the code, and why the code is needed, should be on who put it out first. Yes. But what happens when that code is there, live, working, and the originator is no longer available, and you need to enhance it. You come across a complex section and you can't really see why it's written like that. It feels like you're suggesting that one should just replace it with the simpler version you think will do the job just as well, and see what breaks. Due to my usual context, that approach fills me with horror. I've seen it go wrong too many times ever to be comfortable with it. Admittedly, if you're producing simple web sites then usually it won't be a problem, but when there are potentially millions of dollars of revenue at risk when a condition happens that you didn't anticipate and which was part of the reason the original code was so hairy, you become a little more wary of the "move fast and break things, then fix them" approach. > If we are not brave and decisive when we decide to cut code, the complexity of the codebase will just explode in no time. And if you are brave and decisive and cut code, and it turns out that the complexity was there for a reason you didn't understand, then that can be a company-terminating move. Again, our contexts are different, and yes, I do understand the need for controlling complexity in code, and simplifying where possible. Properly understanding and analysing the risks is something I rarely see. I suspect we'd actually agree in a given context, I'm just horrified to watch people unthinkingly advocating the approach in places where it doesn't apply. I'm not claiming you're one of them, quite possibly you'd do the risk analysis and understand the context, but I've seen it too often to take for granted that otherwise clever people won't do it. "We'll just re-write it, it won't take long, how hard could it be?"
    - siscia 6y ago
      I do actually work on quite low level code. My mistakes are neither millions of euros nor company ending scenario. Just a lot of complaints. I am not advocating for move early and break things fast. Not at all. But in my environment I find the need to find a reasonable compromise. Compromise that can also be having a set of test suites that allow to test things and rollback. I am the one advocating for "clean code is the one you never have to look at, because it works, not the one that looks nice in the editor". I understand your point, I understand that we work in different environments, but I also think that a codebase is a living creature that, if left unchecked, will just explode in complexity. In some environment make sense to tame that complexity, in some other make sense to reduce it!

by siscia 6y ago

ColinWright 6y ago

Except that you don't always know all the ways the system needs to be tested. I've come across code that was broken, seriously broken, multiple thousands of pounds broken, because someone replaced apparently pointless code with something simpler, tested every case they thought of, and deployed it. Are your tests really complete? Have you tested everything? Perhaps we simply work in different fields, and there are things that matter to me that you would shrug off and not care about.

siscia 6y ago
Indeed it is a fine balance. However, what I am trying to convey is that the burder of explaining and testing the code, and why the code is needed, should be on who put it out first. If we are not brave and decisive when we decide to cut code, the complexity of the codebase will just explode in no time. It is already extremely difficult to simplify and remove code, if the person doing this job is also the one that need to figure out, from scratch without documentation, why the code was put there in the first place, the simplification is never going to happen.
- ColinWright 6y ago
  > ... the burden of explaining and testing the code, and why the code is needed, should be on who put it out first. Yes. But what happens when that code is there, live, working, and the originator is no longer available, and you need to enhance it. You come across a complex section and you can't really see why it's written like that. It feels like you're suggesting that one should just replace it with the simpler version you think will do the job just as well, and see what breaks. Due to my usual context, that approach fills me with horror. I've seen it go wrong too many times ever to be comfortable with it. Admittedly, if you're producing simple web sites then usually it won't be a problem, but when there are potentially millions of dollars of revenue at risk when a condition happens that you didn't anticipate and which was part of the reason the original code was so hairy, you become a little more wary of the "move fast and break things, then fix them" approach. > If we are not brave and decisive when we decide to cut code, the complexity of the codebase will just explode in no time. And if you are brave and decisive and cut code, and it turns out that the complexity was there for a reason you didn't understand, then that can be a company-terminating move. Again, our contexts are different, and yes, I do understand the need for controlling complexity in code, and simplifying where possible. Properly understanding and analysing the risks is something I rarely see. I suspect we'd actually agree in a given context, I'm just horrified to watch people unthinkingly advocating the approach in places where it doesn't apply. I'm not claiming you're one of them, quite possibly you'd do the risk analysis and understand the context, but I've seen it too often to take for granted that otherwise clever people won't do it. "We'll just re-write it, it won't take long, how hard could it be?"
  - siscia 6y ago
    I do actually work on quite low level code. My mistakes are neither millions of euros nor company ending scenario. Just a lot of complaints. I am not advocating for move early and break things fast. Not at all. But in my environment I find the need to find a reasonable compromise. Compromise that can also be having a set of test suites that allow to test things and rollback. I am the one advocating for "clean code is the one you never have to look at, because it works, not the one that looks nice in the editor". I understand your point, I understand that we work in different environments, but I also think that a codebase is a living creature that, if left unchecked, will just explode in complexity. In some environment make sense to tame that complexity, in some other make sense to reduce it!