Hacker News new | ask | show | jobs
by Chris2048 1570 days ago
That has nothing to do with giving devs lee-way.

If you work without tests/QA, you are shooting from the hip. The scenario above as-such should not happen. If it ties in with million-dollar processes, even more so. What you are saying is "We don't trust our process, so we do as little as possible outside authorised tasks"; Instead, you should fix the process. If this led to post-mortems and process improvements, as in QA/dev process, not simply bug-fixes, then why is the process not improving and/or better trusted now?

Also, the original task is described as a "refactor", so the numbers should not be affected - was was it not just a refactor?

1 comments

> If this led to post-mortems and process improvements, as in QA/dev process, not simply bug-fixes, then why is the process not improving and/or better trusted now?

IME things do improve after taking those steps. But with large code bases there are a lot of layers of products over time and it's difficult (and expensive) to make sure everything is covered. And it's also a moving target.

> Also, the original task is described as a "refactor", so the numbers should not be affected - was was it not just a refactor?

IME the most useful tech debt interventions are where some legacy module is deleted or some unused code retired. Unfortunately those are often not provably without side effects and sometimes even with a diligent investigation side effects can be missed, especially when the components involved are old and original creators and product managers have left the company.

At the end of the day cleaning up tech debt has non-zero risk, guaranteed cost, and very often, in the eyes of management, negligible reward. So on average it grows and thus enterprise codebases are born.