3 ms·

Yes you should. It is often the simplest way of discovering why it is there - you see what part will break.

by yxhuvud 15y ago

polymatter 15y ago
I think you mean this as part of the investigation in what this code does. That is, after setting up a test/dummy system, you remove the code, run your tests and try to break it. Perhaps sticking in breakpoints or print lines or whatever.. I doubt you really mean to experiment on the business-critical live system. Thats unlikely to be very effective anyway. The most obscure code is often a bug fix for some really obscure bugs. Maybe it fixes some weird bug in Swedish XP SP1, or something which you don't find just by removing it and testing. Situation depending, you will need to actually read and understand the code and investigate properly.
- yxhuvud 15y ago
  Obviously, it is not a tactic to use on a live production system. On the other hand, no programming at all at a live system is the prudent way of doing it. Good test coverage help a lot here though - remove something and you'll get a set of failing tests to investigate.
grannyg00se 15y ago
Or you notice nothing breaks so you leave it out, joyfully congratulating yourself that you reduced total LOC count by one. Then six month later things start breaking and you have no idea why.
- gbog 15y ago
  Refactoring and removing code needs courage and tact, but sometime it needs to be done. If you have a database that is not properly normalized, the more client code you add to it, the harder it is to normalize later. The biggest problem with refactoring and removing code is to explain it to non-techy project managers. If you say that the code or the design is bad, you are saying the guys behind it are bad (you or the previous team), which is not very tactful. I usually try to explain that a software system is a living thing, that need some regular washing up. Also, it is possible to explain that the next features or optimizations will take less time to implement after refactoring.
  - yxhuvud 15y ago
    I tend to blame myself. "I didn't fully understand the problem space when I first wrote it, and now I have to rewrite it because it is a horrible mess and too complex to maintain". Works surprisingly often.

Yes you should. It is often the simplest way of discovering why it is there - you see what part will break.

by yxhuvud 15y ago

Yes you should. It is often the simplest way of discovering why it is there - you see what part will break.

I think you mean this as part of the investigation in what this code does. That is, after setting up a test/dummy system, you remove the code, run your tests and try to break it. Perhaps sticking in breakpoints or print lines or whatever.. I doubt you really mean to experiment on the business-critical live system. Thats unlikely to be very effective anyway. The most obscure code is often a bug fix for some really obscure bugs. Maybe it fixes some weird bug in Swedish XP SP1, or something which you don't find just by removing it and testing. Situation depending, you will need to actually read and understand the code and investigate properly.

yxhuvud 15y ago
Obviously, it is not a tactic to use on a live production system. On the other hand, no programming at all at a live system is the prudent way of doing it. Good test coverage help a lot here though - remove something and you'll get a set of failing tests to investigate.

grannyg00se 15y ago

Or you notice nothing breaks so you leave it out, joyfully congratulating yourself that you reduced total LOC count by one. Then six month later things start breaking and you have no idea why.

gbog 15y ago
Refactoring and removing code needs courage and tact, but sometime it needs to be done. If you have a database that is not properly normalized, the more client code you add to it, the harder it is to normalize later. The biggest problem with refactoring and removing code is to explain it to non-techy project managers. If you say that the code or the design is bad, you are saying the guys behind it are bad (you or the previous team), which is not very tactful. I usually try to explain that a software system is a living thing, that need some regular washing up. Also, it is possible to explain that the next features or optimizations will take less time to implement after refactoring.
- yxhuvud 15y ago
  I tend to blame myself. "I didn't fully understand the problem space when I first wrote it, and now I have to rewrite it because it is a horrible mess and too complex to maintain". Works surprisingly often.