3 ms·

Seems garbage advice to me. Now you've polluted your production code, likely forever. I don't see a situation where using an issue tracker + good commits - e.g.

by dtech 5y ago

Seems garbage advice to me. Now you've polluted your production code, likely forever. I don't see a situation where using an issue tracker + good commits - e.g. 1 commit for the 1 PR linked to the ticket that removes the feature - won't result in a superior situation from a maintenance and traceability perspective.

serial_dev 5y ago
Yes, I agree with you. Another thing is how do you know which of the removed features will be asked to be put back? You can't really know. You can guess, but that will leave you with many classes/functions commented out only in the hope that one day one of them will be requested to be put back. This leads to nobody daring to remove old code for months/years. Then, one day, a new coder on the team just ask WTF is this here, realize it's outdated and not running anymore, and will remove the whole thing. Then, the "senior" guy on the team comes shouting at him/her: "We might need it one day, what do you know about our team, bla bla bla, we had a feature 4 years ago that was removed and we had to add back, so now we have the rule of commenting things out". Yuck, what a nightmare. Just create good commit messages, don't group irrelevant changes together, and you'll be able to find the commit if you really have to. And even if you can't, you know you can still just develop that thing again, right?
- zozbot234 5y ago
  I thought the best practice for "keeping stuff around just in case" was an attic/ directory in the source repo. That way you're still benefiting from version control, but it's also clear that the code is totally untested and might bitrot at any time.
  - dtech 5y ago
    There's little advantage over that vs looking up the old files in source control.
- RMPR 5y ago
  One solution might be to create a separate branch with the feature still available. With time, you kind of get the gut feeling of what could be useful later and what could not.
dt3ft 5y ago
Sure, in a normal world. But with 2 devs in team, handling a clinical information system in very rapidly changing environment (new features), there is no time to document things in this way.
- qayxc 5y ago
  Jump ship then. This sounds like you're travelling towards burnout at supersonic speed. Rapidly changing environment/features is just newspeak for customer has no idea what they even want in the first place and project management is non-existent.
  - dt3ft 5y ago
    I agree and did jump ship. This was in Switzerland, by the way.
- dtech 5y ago
  OK, but that doesn't make it right or good advice. It's just one type of of technical debt due to too much workload.

by dtech 5y ago

serial_dev 5y ago

Yes, I agree with you. Another thing is how do you know which of the removed features will be asked to be put back? You can't really know. You can guess, but that will leave you with many classes/functions commented out only in the hope that one day one of them will be requested to be put back. This leads to nobody daring to remove old code for months/years. Then, one day, a new coder on the team just ask WTF is this here, realize it's outdated and not running anymore, and will remove the whole thing. Then, the "senior" guy on the team comes shouting at him/her: "We might need it one day, what do you know about our team, bla bla bla, we had a feature 4 years ago that was removed and we had to add back, so now we have the rule of commenting things out". Yuck, what a nightmare. Just create good commit messages, don't group irrelevant changes together, and you'll be able to find the commit if you really have to. And even if you can't, you know you can still just develop that thing again, right?

zozbot234 5y ago
I thought the best practice for "keeping stuff around just in case" was an attic/ directory in the source repo. That way you're still benefiting from version control, but it's also clear that the code is totally untested and might bitrot at any time.
- dtech 5y ago
  There's little advantage over that vs looking up the old files in source control.
RMPR 5y ago
One solution might be to create a separate branch with the feature still available. With time, you kind of get the gut feeling of what could be useful later and what could not.

dt3ft 5y ago

Sure, in a normal world. But with 2 devs in team, handling a clinical information system in very rapidly changing environment (new features), there is no time to document things in this way.

qayxc 5y ago
Jump ship then. This sounds like you're travelling towards burnout at supersonic speed. Rapidly changing environment/features is just newspeak for customer has no idea what they even want in the first place and project management is non-existent.
- dt3ft 5y ago
  I agree and did jump ship. This was in Switzerland, by the way.
dtech 5y ago
OK, but that doesn't make it right or good advice. It's just one type of of technical debt due to too much workload.