6 ms·

What prevents the problem from coming back if you stop watching for that?

by Sujan 4y ago

tomrod 4y ago
If the problem is solved, it does not return due to improvements in process. "Watching for it" bifurcates between actively putting into your view (the problem at hand) or by putting a monitoring daemon in place to inform you when a threshold has been broached.
musingsole 4y ago
Don't overthink it. This advice covers 80-99% of actual bugs. Real bugs don't reappear once fixed -- if they do, it means they were never fixed. Metrics designed for a bug that was fixed may be relevant but specifically ARE NOT TARGETED at any new bugs. Though all of this really highlights the core problem with metrics and dashboards and such in the corporate world: if the problem were a problem and not just a convenient political puppet, we'd have solved it by now instead of talking about what thinking about solving it looks like.
- pixl97 4y ago
  I would like you to talk to my programming team about regressions.
  - m3047 4y ago
    I think the argument in this (narrow) discussion would be you haven't fixed (or identified / addressed) the problem.
- eloff 4y ago
  I think applying actual engineering wisdom to software in this case is a mistake. Nobody writes an automated test for a bug and then deletes it once the bug is fixed. You wrote the test in the first place so you get alerted when there is a regression before it gets into production. Regressions happen all the time.
- Too 4y ago
  In isolation, bugs don't suddenly reappear no. So if you only regression test on unit-level, it's very unlikely the test will ever fire red again. What you should do is write use-case regression tests. This will protect you from major regressions, such as "user-registration is taking several minutes", because this is a major bug that can occur for a million new reasons, even if last time the reason was isolated to "database query x was running very slow", your test should track the former, not the latter.

What prevents the problem from coming back if you stop watching for that?

by Sujan 4y ago

What prevents the problem from coming back if you stop watching for that?

If the problem is solved, it does not return due to improvements in process. "Watching for it" bifurcates between actively putting into your view (the problem at hand) or by putting a monitoring daemon in place to inform you when a threshold has been broached.

musingsole 4y ago

Don't overthink it. This advice covers 80-99% of actual bugs. Real bugs don't reappear once fixed -- if they do, it means they were never fixed. Metrics designed for a bug that was fixed may be relevant but specifically ARE NOT TARGETED at any new bugs. Though all of this really highlights the core problem with metrics and dashboards and such in the corporate world: if the problem were a problem and not just a convenient political puppet, we'd have solved it by now instead of talking about what thinking about solving it looks like.

pixl97 4y ago
I would like you to talk to my programming team about regressions.
- m3047 4y ago
  I think the argument in this (narrow) discussion would be you haven't fixed (or identified / addressed) the problem.
eloff 4y ago
I think applying actual engineering wisdom to software in this case is a mistake. Nobody writes an automated test for a bug and then deletes it once the bug is fixed. You wrote the test in the first place so you get alerted when there is a regression before it gets into production. Regressions happen all the time.
Too 4y ago
In isolation, bugs don't suddenly reappear no. So if you only regression test on unit-level, it's very unlikely the test will ever fire red again. What you should do is write use-case regression tests. This will protect you from major regressions, such as "user-registration is taking several minutes", because this is a major bug that can occur for a million new reasons, even if last time the reason was isolated to "database query x was running very slow", your test should track the former, not the latter.